Outcome-label verification: follow-ups from #1077

オープン
  • 何か問題がありますか？
#1,079 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
github, typescript
領域
backend-api-design, documentation, testing

調査の方向性

Start with the named files: reference/configuration/loops.md, run-driver.ts, and the attempt page, then inspect ADR 0022 and the referenced #1055 items. The issue lists timing, retry, settlement, and documentation findings, but does not point to the relevant tests or identify a single scoped change. Done criteria would need to be narrowed to chosen findings and their expected behavior.

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

説明

Follow-ups from the reviews of #1077 (outcome labels verified from the run's label events; closes #1076, #1055 items 2-6). Four factory rounds and one independent review graded these P3; none produces a wrong verdict at today's loop configurations, but the first two can under specific timelines.

Verdict window

  1. On local, ssh and cloudflare workers the writer is the shared App bot, so any outcome label the orchestrator or another run adds as that bot inside the window counts for this run. The window starts at the run's first attempt, so an operator retry days later can accept a ready-for-review the on_green action of another run added in between. Probed: attempt 1 on 11-08, App-bot label on 11-10, retry on 11-11 with an agent that added nothing → Success. State the shared identity in reference/configuration/loops.md, and consider bounding the window to the current attempt plus the earlier attempts' own label events (not any event by the same bot).
  2. A verdict label from an earlier cycle that is still on the item and that the reviewer reaches again produces no GitHub event when re-added, so the first attempt fails without fallback. #1055 item 6 asks for the strictness; the guide and loops.md should tell agents to remove a stale verdict before re-adding it, or the review task should do it.
  3. Rounding the boundary down to the second admits an App-bot label added in the same second just before the first attempt started. Documented trade-off in ADR 0022; keep unless a case shows up.
  4. writerOf takes the worker kind from the current configuration, not from the kind the attempt ran under. A kind change before a recovered completion settles reads the wrong bot's events without fallback. An unconfigured worker in a mixed-history run skips that writer instead of falling back (mutation survives).

Reads and hold time

  1. The deterministic "more than 10 pages" InvalidGitHubResponseError is retried: up to three walks of up to ten GraphQL pages per writer, and a run that used two worker kinds walks twice. Do not retry it, and filter by actor server-side if the timeline query allows it.
  2. Total settlement hold with both reads failing is about 96 s (2 × (3 × 15 s + 3 s)) with the worker slot held; the docs give only per-read numbers. State the bound, or run the bot-account lookup and the events read under one budget.
  3. The per-writer timeline reads run with concurrency: "unbounded"; sequential passes every test. Pick one and say why.

Settlement path

  1. retryingStore can be removed from the pre-verification snapshot and from the outputs write in run-driver.ts with every engine test green; only the finishAttempt write is pinned.
  2. discardedSuccess ignoring NoOpenAttempt survives; the cost is one wasted GitHub read before finishAttempt returns Unchanged.
  3. RejectedCompletion is checked before the CI handoff checks in finishAttempt, so a CI-required loop with no pushed head reports the missing label, not the missing head. Unchanged from main; decide the order and test it.
  4. The attempt page shows the AgentFailure text for a rejected completion but not the kept report message; show both.

Docs and packaging

  1. The changeset says patch for the moved @usine/engine/completion-check export while the pending verify-loop-outcomes.md already bumps engine minor; align them. ADR 0022 has a double blank line before the new amendment. docs/architecture/index.mdx is pinned to an older commit and does not list the new subpath.
  2. #1055 items 1 and 7-12 stay open there.
主要言語
TypeScript
スター
1
フォーク
0
平均マージ
3時間 23分
マージ済み PR（30日）
400

環境構築

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

はじめの一歩

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

basaltbytes/usine のほかの issue

basaltbytes/usine の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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