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

test: dequeue expiry contract test fails on slow Postgres

Chiusa Adatta ai principianti
#997 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #1022 di @stromanni — integrata

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
84/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
postgresql, rust

Direzione di ricerca

Inizia da crates/flexiq-core/tests/rust/storage_tests.rs, in particolare da test_dequeue_reports_expired_jobs e dalla seconda chiamata a dequeue_from_reporting; esamina postgres/jobs.rs::scan_dequeue_candidates ed esegui il comando cargo test fornito con Postgres ospitato. Il lavoro è completato quando il test del contratto passa in modo affidabile con Postgres lento e vengono raggiunti i test di storage registrati successivamente.

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

Descrizione

postgres_storage_tests fails deterministically against a hosted Postgres (Neon, both the pooled and the direct endpoint), on master as well as on feature branches:

panicked at crates/flexiq-core/tests/rust/storage_tests.rs:204:5:
assertion `left == right` failed
  left: None
 right: Some("<live job id>")

The failing assertion is in test_dequeue_reports_expired_jobs, on the second half, the single-job dequeue_from_reporting call. The first half, the batch dequeue, passes.

Likely cause: the test, not the dequeue

The test reads now = now_millis() once at its start and dequeues at now + 1_000 in both halves. Each enqueued job's scheduled_at is the wall clock at the time it was enqueued, and the Postgres candidate scan (postgres/jobs.rs::scan_dequeue_candidates) keeps only scheduled_at <= now.

A hosted database adds a few hundred milliseconds per round trip. By the time the second pair of jobs is enqueued, more than a second has passed since now was read. Their scheduled_at is therefore later than now + 1_000, the scan returns no candidates, and the claim comes back None. A CI Postgres container answers fast enough that the window never closes, which is why CI stays green.

Why it matters

run_storage_tests stops at this panic. Every contract test registered after test_dequeue_reports_expired_jobs never runs against a hosted Postgres, so a regression in any of them goes unseen locally.

Suggested fix

Take a fresh now_millis() for each half, or pass now_millis() + 1_000 at the dequeue call itself. That keeps expires_at in the past and scheduled_at in the past relative to the dequeue time, however slow the backend is. Other tests that capture now once and dequeue later may share the pattern and are worth checking.

Repro

FLEXIQ_POSTGRES_TEST_URL=<hosted postgres url> \
  cargo test -j1 -p flexiq-core --features postgres --test rust -- postgres
Lingua principale
Rust
Stelle
20
Fork
2
Merge medio
8h 15m
PR unite (30g)
66

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 ByteVeda/flexiq

Tutte le issue di ByteVeda/flexiq

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.