Abbruch und Fristen in Go mit context.Context

Ziel

Jede an eine Anfrage gebundene Arbeit in einem Go-Dienst von aussen stoppbar machen, mit begrenzter Lebensdauer, unter Verwendung des context-Pakets der Standardbibliothek statt selbstgebauter Stop-Channels.

Voraussetzungen

Die Regeln der Paketdokumentation: Ein Context ist der erste Parameter, benannt ctx; er wird nicht in einer Struct gespeichert; nil wird nie übergeben (context.TODO() bei Unklarheit); Werte tragen nur anfragebezogene Daten, die API-Grenzen überschreiten, keine optionalen Parameter. Kenntnis darüber, welche Bibliotheken einen Kontext entgegennehmen (net/http-Anfragen, database/sql, die meisten Clients).

Schritte

1. Bei der Wurzel beginnen: Ein HTTP-Handler erhält r.Context(), der laut net/http-Dokumentation abgebrochen wird, wenn die Verbindung des Clients schliesst, wenn die Anfrage abgebrochen wird (HTTP/2) oder wenn ServeHTTP zurückkehrt; ein main oder Worker erzeugt einen eigenen mit signal.NotifyContext, damit SIGTERM ihn abbricht.
2. Für jede zeitlich begrenzte Operation einen Kindkontext ableiten: ctx, cancel := context.WithTimeout(ctx, 2*time.Second), unmittelbar gefolgt von defer cancel(). Die Dokumentation hält fest, dass das Unterlassen des Cancel-Aufrufs zu einem Leck des Kindkontexts führt, bis der Elternkontext abgebrochen wird, und dass go vet dies prüft.
3. ctx in jeden Aufruf übergeben, der blockieren kann: http.NewRequestWithContext, db.QueryContext, und Channel-Operationen in einem select mit einem case <-ctx.Done() einbetten.
4. In Schleifen und langen Berechnungen an den Iterationsgrenzen ctx.Err() prüfen und zurückgeben; der Wert ist context.Canceled oder context.DeadlineExceeded.
5. Bei bewusstem Abbruch context.WithCancelCause verwenden und den Grund festhalten; Aufrufer lesen ihn mit context.Cause(ctx) (Go 1.20 und später).
6. Für Arbeit, die die Anfrage überdauern muss (ein Audit-Schreibvorgang, ein Cache-Füllvorgang), von context.WithoutCancel(ctx) ableiten (Go 1.21), damit Werte erhalten bleiben, sich der Abbruch aber nicht fortpflanzt, und ihr ein eigenes Timeout geben.
7. Den Abbruchpfad testen: einen Kontext mitten in einem Aufruf abbrechen und prüfen, dass die Funktion umgehend mit einem Fehler zurückkehrt, der ctx.Err() umschliesst.

Erwartetes Ergebnis

Eine abgebrochene Anfrage oder eine abgelaufene Frist wickelt den gesamten Aufrufbaum ab; keine Goroutine fragt weiter eine Datenbank für einen Client ab, der längst weg ist. Timeouts werden einmal, nahe der Grenze, gesetzt und schrumpfen entlang der Kette von selbst, weil eine Kindfrist, die später liegt als die der Eltern, ignoriert wird.

Grenzen und Prüfbasis

Abbruch ist kooperativ: Code, der ctx ignoriert, läuft weiter, bis er von selbst zurückkehrt, und eine CPU-gebundene Schleife, die nie ctx.Err() prüft, wird nicht unterbrochen. Die Schritte folgen der zitierten Paketdokumentation und der Einführung im Go-Blog; es werden keine Zeitangaben behauptet.

Shutdown ist kein Abbruch

Der Kontext aus signal.NotifyContext sollte den Stopp auslösen, nicht der Elternkontext jeder Anfrage sein. Ihn in http.Server.BaseContext einzuhängen bricht alle laufenden Anfragen in dem Moment ab, in dem SIGTERM eintrifft – genau der Fehlerschub, den ein geordneter Stopp vermeiden soll. Stattdessen auf den Signalkontext warten und dann srv.Shutdown(shutdownCtx) mit einem frischen context.WithTimeout(context.Background(), 20*time.Second) aufrufen: Der Server nimmt keine neuen Anfragen mehr an, und aktive Anfragen behalten ihre eigenen Kontexte, bis sie zurückkehren oder die Frist verstreicht. Den Signalkontext nur direkt für Arbeit verwenden, die sofort stoppen soll: Queue-Konsumenten, Polling-Schleifen, Hintergrund-Scheduler. Shutdown wartet nicht auf gekaperte Verbindungen wie WebSockets; diese über einen RegisterOnShutdown-Callback schliessen.