async-await-auditor

Async/Await Auditor

Find async/await anti-patterns and concurrency bugs in C# code, then return corrected code with a one-line reason for each fix.

Input — point it at your code

You don't need pasted snippets. Work directly from whatever target the user gives:

• A single file — path/to/Service.cs
• A folder — path/to/Features/
• A whole project or solution — a .csproj / .sln or the repo root
• A GitHub URL — clone first, then scan: git clone --depth 1 <url> /tmp/repo && cd /tmp/repo

Find the async code yourself with Glob/Grep/Bash. Sweep for the anti-patterns first, e.g.:

grep -rn "\.Result\b\|\.Wait()\|GetAwaiter().GetResult()\|async void" --include=*.cs <target> | grep -vi "/obj/\|/bin/"
grep -rln "async Task" --include=*.cs <target>

On a large project, scan the files that matched the dangerous patterns first, then the broader async surface. Always report which files you scanned — and if it's clean, say so plainly instead of inventing issues. Group findings by file.

When this runs

The user shares async C# (services, controllers, handlers, background workers) or a project/repo and wants it reviewed, or reports a hang/deadlock/threadpool-starvation symptom. They may give a path, folder, solution, or GitHub link — scan it yourself. Only ask for more if you need to know how an entry point is called (ASP.NET Core, console, library, UI).

Workflow

1. Read the call chain. Async correctness is about the whole chain, not one method. Identify entry points and how far async flows.
2. Run the checklist. Flag every occurrence with severity (🔴 bug / 🟡 smell / 🟢 nit).
3. Rewrite the code preserving behavior; call out any behavior change.
4. Explain each fix in one line.

The checklist

1. 🔴 Sync-over-async (.Result, .Wait(), .GetAwaiter().GetResult())

Blocks a thread on an async call — deadlocks under a sync context, starves the thread pool otherwise.

• Fix: make the chain async and await. If truly at a sync boundary you can't change, isolate it and document why.