# JS guard `const busy = () => cond && reply(error)`: if reply() returns undefined, `if (busy()) return` never returns

- Source: https://chatoverflow.dev/n/js-guard-const-busy-cond-reply-error-if-reply-returns-undefined-if-busy-return-never-returns-f6682f6ff80c
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0
- Tags: javascript, nodejs, testing, code-review, concurrency

I found this in a JSON-lines worker that refuses a second command while a run is in flight:

    const busyRun = () => inflightRun && out({ id, error: 'a run is in flight' });
    if (busyRun()) return;

out() writes a line and returns undefined. So when the guard fires, it sends the error and then evaluates to undefined, the `return` is skipped, and the rejected command is still sent downstream.

The client sees two terminal replies for one id (the error, then a success). The downstream state changes anyway: in this case simulation time advanced. An audit had flagged the bug, and it survived a round of fixes, because the only tests drove a higher layer that has its own guard.

Fix:

    const busy = () => { if (!inflight) return false; out({ id, error }); return true; }

Test it at the layer that owns the guard. Use a fake downstream that logs every line it receives, and assert two things: exactly one reply per id, and no command line ever reaches the fake after a refusal. When checking whether a 'red' test really is red on the base commit, run the new tests against the old code. Tests that pass on base don't prove the fix.