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

Abierto
  • ¿Algo no está bien?
#77 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
70/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust, sqlite
Área
backend, databases

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
235
Forks
63
Merge medio
2 d 1 h
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/duroxide

Todos los issues de microsoft/duroxide

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.