Zum Hauptinhalt springen
ai-slop/csharp-sync-over-asyncmanuelle Behebung

Sync over Async.

Blockierendes Warten auf einen Task mit `.Result`, `.Wait()` oder `.GetAwaiter().GetResult()`. Es bindet einen Thread und kann unter einem Synchronisationskontext zum Deadlock führen.

Beanstandete und saubere Form.

Jedes Beispiel zeigt genau die Codeform, nach der die Regel sucht, und dann die kleinste Version, die die Absicht bewahrt, ohne Risiken zu verstecken oder Rauschen hinzuzufügen.

csharp-sync-over-async.cs
✗ Beanstandet
public User GetUser(int id)
{
    return _client.GetUserAsync(id).Result;
}
Warum das anschlägt

Deterministischer Zeilenabgleich auf maskiertem Quelltext: beanstandet Member-Zugriffe auf `.Result`, `.Wait()` und `.GetAwaiter().GetResult()`.

csharp-sync-over-async.cs
✓ Sauber
public async Task<User> GetUserAsync(int id)
{
    return await _client.GetUserAsync(id);
}
Was sich geändert hat

Nutze `await` für den Task und mach den Aufrufer async. Hältst du tatsächlich einen abgeschlossenen Task und musst blockieren, ergänze einen kurzen Kommentar, der diese Invariante benennt.

Muss eine async-API aus synchronem Code aufgerufen werden, blockieren Agenten darauf, statt den Aufrufer async zu machen. Im schnellen Test funktioniert es, in UI- oder klassischen ASP.NET-Kontexten gibt es einen Deadlock.

Wie diese Regel begründet ist.

Regel-ID

ai-slop/csharp-sync-over-async

Prüfende Engine

ai-slop

Erkennungsstrategie

Deterministischer Zeilenabgleich auf maskiertem Quelltext: beanstandet Member-Zugriffe auf `.Result`, `.Wait()` und `.GetAwaiter().GetResult()`.

Legitimer Code, der NICHT beanstandet wird

Aufrufe mit einem `//`-Kommentar in einer der beiden Zeilen darüber (der begründet, warum Blockieren sicher ist) sowie `.Wait(...)`-Überladungen mit Argumenten werden nicht beanstandet.

Belege

Teil des C#-Regelsatzes von aislop. Vollwertige C#-Unterstützung, einschließlich C#-spezifischer AI-Slop-Regeln, kam mit aislop v0.14.1.