Mocha v4 Exit Policy Transition: Default Drain vs --exit

Direct Recommendation

Use --exit in CI for deterministic job termination. Keep the default drain behavior (--no-exit) for local development to surface resource leaks early. This matches Mocha's own documentation guidance and balances CI reliability with diagnostic visibility.

Why the Default Changed

Mocha v4.0.0 (March 2018) switched from forced process.exit() to allowing the event loop to drain naturally. The old behavior masked leaks by killing pending timers, sockets, and server handles. The new default exposes those leaks as hung processes — exactly what you want during development.

Verify Your Suite Releases All Handles

Run this sequence locally to confirm cleanup before changing CI policy:

1. npx mocha — default drain. If it hangs, proceed.
2. Add a temporary after() hook in your test setup:

   after(() => {
     console.log('Active handles:',
       process._getActiveHandles().map(h => h.constructor.name)
     );
   });

3. Run again. The output identifies lingering handle types (e.g., Timer, TCP, Pipe).
4. Fix each leak: close servers, clear intervals, end database pools, await promises.
5. Re-run npx mocha — it should exit cleanly.

Assumption: You're on Mocha ≥ 4.x and Node ≥ 8.x. Verify with npx mocha --version.

CI Exit Strategy Criteria

Factor	Prefer --exit	Prefer Default Drain
CI timeout strictness	Hard wall required (e.g., 10 min max)	Generous or no timeout
Leak history	Frequent leaks in third-party deps	Clean suite, leaks rare
Team workflow	Developers run CI-like commands locally	Developers run mocha directly
Flakiness tolerance	Zero tolerance — hung jobs block merges	Can investigate occasional hangs

Safe CI Command Pattern

Combine a shell timeout with --exit for a hard guard that still surfaces leaks locally:

timeout 120 npx mocha --exit

Adjust 120 (seconds) to your suite's normal runtime plus margin.

One Diagnostic Detail That Changes the Recommendation

Does your test suite intentionally keep handles alive after tests (e.g., a long-running server for manual inspection)? If yes, do not use --exit — it will kill that server. Instead, fix the suite to close handles in after() hooks, or run the server in a separate process.