Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

test: dequeue expiry contract test fails on slow Postgres

クローズ 初心者向け
#997 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

関連するプルリクエストがすでにマージされています。

  • #1022 @stromanni による — マージ済み

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
84/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
postgresql, rust

調査の方向性

crates/flexiq-core/tests/rust/storage_tests.rs から始め、特に test_dequeue_reports_expired_jobs と 2 回目の dequeue_from_reporting 呼び出しを確認します。postgres/jobs.rs::scan_dequeue_candidates をレビューし、提供されている cargo test コマンドをホストされた Postgres に対して実行します。低速な Postgres でもコントラクトテストが安定してパスし、その後に登録された storage テストまで到達すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
Rust
スター
20
フォーク
2
平均マージ
10時間 50分
マージ済み PR(30日)
61

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ByteVeda/flexiq のほかの issue

ByteVeda/flexiq の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。