fix(scheduler): clarify durable queued count in queue status

オープン
#263 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust
領域
api, backend, testing

調査の方向性

Start by tracing Scheduler::queue_status and JobQueries::list_dispatchable to confirm how pending and queued rows are counted in the scheduler.queue.v2 response. Then find the API contract, Control Center and monitoring consumers, fixtures, and queue status integration test. Done means the response and docs clearly distinguish planned pending rows from durable queued work, compatibility behavior is explicit, and the mixed-row integration test and required CI checks pass.

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

説明

Problem

The scheduler.queue.v2 response includes the field durable_pending, but Scheduler::queue_status sets it to the number of rows returned by JobQueries::list_dispatchable, which selects only rows whose status is queued. It does not count database rows whose status is pending.

During the 2026-10-05 live audit, the jobs table had hundreds of planned pending rows while the authenticated queue endpoint correctly reported durable_pending=0 and queued_total=0. The mismatch made the response easy to misread and initially caused the durable planned-row count to be mistaken for runnable queue backlog.

Required change

Provide an accurately named durable dispatchable count, such as durable_queued, and document the existing field semantics. Preserve compatibility with existing v2 consumers: either retain durable_pending as a deprecated alias for a documented transition window or introduce an explicit contract-versioned response change. Update Control Center and monitoring consumers and fixtures together.

Acceptance criteria

  • API and docs distinguish pending (planned DAG work) from queued (durable dispatchable work).
  • The returned durable queued count equals the count of rows whose status is queued for the same snapshot; planned pending rows do not inflate it.
  • Compatibility behavior is explicit and tested; no existing consumers break silently.
  • Queue status integration test includes a mixture of pending and queued rows and asserts the response fields.
  • Aegis and GitForge CI checks pass for the change before merge.

No production state or queue rows should be mutated for this change.

主要言語
Rust
スター
1
フォーク
0
平均マージ
1日 7時間
マージ済み PR(30日)
32

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

aliasfoxkde/GitForge のほかの issue

aliasfoxkde/GitForge の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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