Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

rivetkit: 'failed to sync scheduled actor alarm' (transaction_closed) about once per minute per idle actor; scheduled wakes still fire on time

Aperta
  • Qualcosa non va?
#5,881 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust, sqlite
Ambito
backend, databases

Direzione di ricerca

Start by searching the Rust source for the log message 'failed to sync scheduled actor alarm' and the query 'SELECT MIN(trigger_at) FROM _rivet_schedule_events', then trace the actor sleep path that runs after the SQLite transaction coordinator closes. Reproducing needs an actor with nothing scheduled that goes idle for about a minute. Done means that path no longer logs transaction_closed while scheduled wakes still fire on time.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Version: rivetkit 2.3.26 (LocalNative sqlite backend), @rivet-dev/pi 0.5.2, @earendil-works/pi-durable 1.2.0. One actor per agent, about 14 actors on one runner process.

Symptom. For every actor, roughly once every 61 s, the runner logs:

level=error message="sqlite operation failed" backend=LocalNative operation=query
  sql="SELECT MIN(trigger_at) FROM _rivet_schedule_events" code=transaction_closed
  error_message="SQLite transaction coordinator is closed."
level=error message="failed to sync scheduled actor alarm"  (error chain: transaction_closed)

The actor's generation counter climbs with it (about one generation per minute per actor), so each actor seems to wake and sleep roughly once a minute.

Expected. No error when an actor sleeps with nothing scheduled, or the alarm sync runs before the transaction coordinator is closed on the sleep path.

What we measured

  1. The cadence is steady (for one actor: 16:22:20, 16:23:22, 16:24:23) and independent of client traffic: it continued while our own client loops were idle.
  2. It is not our own scheduling. We checked our incident-retry alarm (no incident exists on any actor), our config sync (digest-deduped, runs at process start only), our message-ingress loop (quiet during the errors), and @rivet-dev/pi's long-wait wake (we instrumented the c.schedule.at(...) call for it: zero calls while the errors kept appearing).
  3. Impact: none found. We had an idle actor schedule a wake 90 s out through c.schedule.after. It fired on time (about 90.0 s after scheduling, within roughly a second) while the same actor kept logging the sync failure. Scheduled alarms are therefore not being lost; the error looks like noise in the sleep path.

Questions

  • Which timer wakes an idle actor about every 61 s (an engine-side keepalive?)
  • Why does the alarm sync run after the transaction coordinator is closed on the sleep path, and is the error safe to ignore?

Happy to provide more logs or run a probe.

Lingua principale
Rust
Stelle
6.3k
Fork
279
Merge medio
1g 9h
PR unite (30g)
53

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rivet-dev/rivet

Tutte le issue di rivet-dev/rivet

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.