Will It Vibe?Synchronous child_process call in a request-handler file
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
execSync/spawnSync/execFileSync blocks the calling thread until the subprocess exits. In a file whose path looks like a request handler, that stalls every concurrent request for as long as the subprocess runs, which is worse than a slow disk read. Heuristic: the path suggests a handler, but the call could be at startup instead.
Why it matters
execSync/spawnSync/execFileSync block the calling thread until the subprocess finishes, and Node has only one thread running your JavaScript. If this file is really a request handler, a slow or hanging subprocess call stalls every other concurrent request for as long as it runs, which is a more severe version of the same problem as a synchronous disk read. This is a path-based heuristic: the call could also be one-time setup code that happens to live in a routes/api/handlers file.
How to fix it
Switch to the async variant: child_process.exec/execFile/spawn with a callback, or their util.promisify'd/exec-promise forms with await. If the call only ever runs once at startup, move it out of the request-handling file into an explicit init function so it is clearly not on the request path.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo