SQLite: order orchestration fetches by readiness (visible_at, then id), as PostgreSQL does

Aperta
  • Qualcosa non va?
#77 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
70/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust, sqlite
Ambito
backend, databases

Direzione di ricerca

Start with the two ORDER BY q.id orchestrator fetch queries in src/providers/sqlite.rs (around lines 781 and 800) and compare them with the readiness ordering in duroxide-pg's migrations/0025_fetch_orchestration_lease_at_claim.sql. Add a migration under migrations/ for the index, then add provider validation tests next to test_worker_deferred_item_does_not_starve_ready_work in src/provider_validation/queue_semantics.rs. Done when the abandon and timer cases both pass against SQLite.

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

Descrizione

enhancement

Follow-up from #74. Low priority: consistency with PostgreSQL and future-proofing, not a merge blocker. Line numbers are at 112dcf0.

Problem

#74 changed the SQLite worker fetch to ORDER BY q.visible_at, q.id, so work that becomes ready late no longer goes ahead of work that was ready earlier. The orchestrator queue still picks the ready row with the lowest id: ORDER BY q.id in src/providers/sqlite.rs:781 (with a capability filter) and :800 (without).

PostgreSQL already orders this fetch by readiness: duroxide-pg migrations/0025_fetch_orchestration_lease_at_claim.sql:85 and :95 use ORDER BY q.visible_at, q.id. The two providers disagree, and no provider validation test checks the order.

Two kinds of rows become ready long after they get their id:

  • TimerFired rows are inserted when the timer is scheduled, with visible_at = fire_at (sqlite.rs:1587-1590). A one-hour timer carries an id from an hour earlier.
  • abandon_orchestration_item with a delay keeps the row and its id and moves visible_at (sqlite.rs:2248-2250). The dispatcher does this for an incompatible version (src/runtime/dispatchers/orchestration.rs:442), history that fails to deserialize (:585), a continue-as-new successor that is not visible yet (:624), an unregistered orchestration (:745), and exhausted failure-commit or ack retries (:1048, :1239).

Under a backlog, these rows go ahead of instances that have been ready longer.

Impact

Low. Every orchestration abandon uses up an attempt, so a failing instance can jump the queue at most max_attempts times before it is poisoned, and a timer fires once. This is priority inversion, not starvation. Correctness is not affected: one fetch takes all ready messages of the chosen instance (sqlite.rs:876-889), in id order (:896). It matters most in bursts, such as a deploy that drops an orchestration registration, or many timers firing together.

Proposed change

  1. ORDER BY q.visible_at, q.id in both orchestrator queries (sqlite.rs:781, :800).
  2. A migration with CREATE INDEX IF NOT EXISTS idx_orch_ready_order ON orchestrator_queue(visible_at, id);. File-backed databases get indexes only through migrations/ (sqlx::migrate! at sqlite.rs:172), as f8d4db7 did for the worker queue. The existing idx_orch_visible(visible_at, lock_token) breaks ties by lock_token, not id.
  3. A provider validation test, the orchestration counterpart of test_worker_deferred_item_does_not_starve_ready_work (src/provider_validation/queue_semantics.rs:121):
    • Abandon: start instances A and B, fetch A, abandon it with a 1 ms delay, and wait 20 ms. The next fetch must return B.
    • Timer: enqueue a TimerFired for A that fires in 10 ms, then a message for B. After 20 ms, the next fetch must return B, which became ready first.

By code reading, SQLite fails the timer case today and PostgreSQL passes it.

Filed for @affandar from the #74 review.

Lingua principale
Rust
Stelle
235
Fork
63
Merge medio
2g 1h
PR unite (30g)
7

Preparare l'ambiente

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 microsoft/duroxide

Tutte le issue di microsoft/duroxide

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.