PeriodicJobEnqueuer logs ERROR "Error starting transaction: context canceled" when the client stops during the leader's staggered start

Offen Anfängerfreundlich
#1,576 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
66/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
go, postgresql
Bereich
backend

Rechercherichtung

Der ERROR stammt von insertBatch in internal/maintenance/periodic_job_enqueuer.go, das s.exec.Begin(ctx) aufruft, nachdem StaggerStart bei einem abgebrochenen Kontext zurückkehrt. Beginne mit dem Warten in der Stagger-Phase und dem Einfügepfad für Start-Jobs an dieser Stelle, und prüfe, wie Client.Stop die Maintenance-Dienste abbricht. Fertig ist, wenn ein Stop während des Staggerns des Leaders keinen ERROR protokolliert, während ein echter Datenbankfehler weiterhin einen ERROR protokolliert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

### What happens

When a client that has just become the leader is stopped (SIGTERM → Client.Stop or the cancellation of the context passed to Client.Start) within the first ~0.1–2.5 s, the log gets an ERROR line even though the stop is a normal, requested shutdown:

{"level":"ERROR","msg":"maintenance.PeriodicJobEnqueuer: Error starting transaction","error":"context canceled"}
Outside that window the shutdown log is clean.

Why (as far as we can tell from the source)
The maintenance services start with StaggerStart, a cancellable sleep of a random 0–1 s per service, in sequence.
Client.Stop (and the cancellation of the start context) cancels the context of the maintenance services at once.
PeriodicJobEnqueuer wakes up from the stagger with the cancelled context and still goes on to insert the start jobs (RunOnStart periodic jobs): insertBatch calls s.exec.Begin(ctx), which fails with context.Canceled, and the error is logged at ERROR (internal/maintenance/periodic_job_enqueuer.go, insertBatch, "Error starting transaction").
Seen on v0.49.0; the same code is in v0.51.0.

Reproduction
A client with at least one PeriodicJob with RunOnStart: true, alone in the database so it becomes the leader at once.
Start it and stop it about 100 ms after it reports it is the leader (e.g. a process that gets SIGTERM right after its readiness probe).
Repeat a few times: most runs log the ERROR line above.

Expected
A requested stop does not log an error. For example, the enqueuer could return without inserting when ctx.Err() != nil after the stagger (or before Begin), or log a context cancellation during stop at a lower level, as other maintenance services do on shutdown.

Workaround we use
Our runner starts the client on a context that is not cancelled by the process shutdown and, before calling Stop, waits (bounded, a few seconds) until the leader's start jobs are in river_job or another client leads. It works, but it couples the shutdown to a database poll and delays a SIGTERM that arrives right after start.

Environment: River v0.49.0, riverpgxv5, PostgreSQL 18, Go 1.27.

Claude find it, he's always finding

Vorherrschende Sprache
Go
Sterne
5.9k
Forks
197
Ø Merge
1 T. 4 Std.
Gemergte PRs (30 T.)
120

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus riverqueue/river

Alle Issues in riverqueue/river

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.