Will It Vibe?Synchronous fs 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
A blocking fs.*Sync call appears in a file whose path looks like a request handler (routes/, api/, handlers/). If it runs per-request it stalls the whole process for every concurrent client until the disk I/O finishes. Heuristic: the path suggests a handler, but the call could be at module load time instead.
Why it matters
A synchronous fs call (readFileSync, writeFileSync, and friends) blocks the entire Node process until the disk I/O completes, and Node has only one thread running your JavaScript. If this file is really a request handler, every other concurrent request waits behind that one disk operation, so latency spikes under load even though nothing looks wrong in a single-user test. 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: fs.promises.readFile/writeFile (or fs.readFile/writeFile with a callback) and await it. If the call only ever runs once at startup before the server accepts traffic, moving it out of the request-handling file (or to an explicit init function) removes the ambiguity entirely.
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