Will It Vibe?Thread.sleep() in a file that also uses reactive/async types
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
Thread.sleep() blocks whatever thread calls it. In a file that also uses Mono/Flux (Project Reactor), CompletableFuture, or @Async, that thread is often one of a small pool the framework needs for everything else, so blocking it can stall unrelated work. Heuristic: file-level co-occurrence, not proof this exact call runs on a shared scheduler thread; use the delay/timer operator the framework provides instead.
Why it matters
Thread.sleep() blocks whatever thread calls it. Project Reactor (Mono/Flux), CompletableFuture pipelines, and Spring's @Async all rely on a comparatively small pool of threads (or, on WebFlux, a handful of event-loop threads) to get through all in-flight work; blocking one of those threads for a sleep's duration can starve unrelated requests that were waiting for that same thread. This detector only checks that the same file also uses one of these reactive/async types somewhere, not that this exact Thread.sleep() call runs on a shared scheduler thread.
How to fix it
If this code runs on a reactive/async execution path, replace the sleep with the non-blocking equivalent the framework provides: Mono.delay()/Flux.delay() for Reactor, or a scheduled executor for CompletableFuture-based code. If it genuinely runs on its own dedicated thread (a background worker, not a shared reactive scheduler), Thread.sleep() there is fine and can be left as-is.
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