Blocking synchronous I/O in request handler
Part of Architecture & Best Practices, which counts for 15% 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
fs.readFileSync/writeFileSync inside request-handling code blocks the Node event loop for all concurrent requests.
Why it matters
Node serves every request on one event loop, so a synchronous file read inside a handler freezes all in-flight requests until the disk responds. Under load, one slow sync call becomes site-wide latency spikes that are hard to attribute. The async versions cost one await.
How to fix it
Replace fs.readFileSync and fs.writeFileSync in request paths with the promise API: await readFile/writeFile from 'node:fs/promises', marking the handler async. If the same file is read on every request but rarely changes, load it once during startup (or lazily behind a cached promise) instead of per request. The problem is per-request blocking, so the goal is that no sync file I/O runs while requests are being served.
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