There are a number of tests (rollback_too_new.js, rollback_collMod_fatal.js, rollback_cmd_unrollbackable.js) that will try to induce a rollback that causes a node to fassert. Most of them will, at the end of the test, restart a node that they expect to then go into rollback and fassert. Whenever we start up a node in a JS test again, we can optionally wait for a connection to it. For a node being restarted that we expect to immediately fassert, though, this "wait for connection" behavior is inherently flaky, since we have no way of controlling how quickly the node will start up and then crash. So if we try to connect after the crash has already occurred, the test will fail since it wasn't able to connect to the node. We can fix this issue by simply not waiting for a node connection if it is not necessary. For a node that we expect to fassert right after startup, we shouldn't need to re-connect to it.