Will It Vibe?I/O or network result unwrapped/expected directly
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 filesystem or network call is chained directly into `.unwrap()`/`.expect(...)`, so any I/O failure (missing file, permission denied, connection refused) panics the process. Heuristic: proximity-based, scoped to the same statement/chain as a known I/O or network call.
Why it matters
Filesystem and network operations fail constantly in the real world: files get deleted or locked, permissions change, disks fill up, connections get refused or time out. Chaining .unwrap()/.expect(...) straight onto one of these calls means the very first time that happens in production, the whole process panics instead of returning an error the caller could retry, log, or surface to a user. This is one of the most common ways a working demo turns into a service that crashes under real conditions.
How to fix it
Propagate the error instead of unwrapping it: use the ? operator in a function that returns a Result (std::io::Result, anyhow::Result, or your own error enum), or explicitly match/if-let on the Result and handle both the Ok and Err cases. For genuinely unrecoverable startup-time failures (a missing required config file, for example), a clear expect("message explaining what is required") is more honest than a bare unwrap(), but a normal request-handling path should not panic on I/O.
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