Will It Vibe?Sync-over-async via GetAwaiter().GetResult()
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
.GetAwaiter().GetResult() blocks the calling thread on an async operation instead of awaiting it. In a context with a synchronization context or a limited thread pool (classic ASP.NET, some UI apps) this is a well-known deadlock pattern, and even where it cannot deadlock it wastes a thread for the duration of the call.
Why it matters
.GetAwaiter().GetResult() blocks the current thread until the awaited operation completes, defeating the purpose of the async call beneath it. In a context that has a synchronization context expecting to resume on the original thread (classic ASP.NET, some desktop UI frameworks), this specific pattern is a well-documented cause of deadlocks. Even in contexts where it cannot deadlock, it ties up a thread for the full duration of the operation instead of freeing it, which shows up as reduced throughput under load.
How to fix it
Make the calling method async and use await instead of .GetAwaiter().GetResult(), propagating async up the call chain as needed. If the call truly must stay synchronous (for example, a legacy interface you cannot change), consider Task.Run(() => ...).GetAwaiter().GetResult() to at least avoid the synchronization-context deadlock, but prefer making the caller async wherever that is possible.
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