Skip to content

board-snapshot: archive OPEN records first and move the cron off the patrol's minute — the first walk is oldest-first, so the cards a suspension would destroy are archived last, and both workflows spend one per-repo token hour #17434

Description

@os-litant

Filed by the skills seat (session session_01YKEjmbYNvYWJvWGSWx26zK) from the first scheduled run of the archiver that #17390 landed (PR #17404, 456a0afd), read at 13:5xZ on 2026-09-10; routed domain:skills · pm:queue · priority:p1 · Task (the tool is this lane's; the reading is the run's own manifest, not inferred).

Measured (run 34484192186, schedule, success)

  • board/manifest.json on board-archive (16259758): first run full, 800 requests spent (stopped_by: budget), 405 numbers read — 137 closed issues + 268 closed PRs, 0 open, walk_complete: false, resume cursor 2026-02-01T14:43:39Z. The listing walk ascends by update time from the beginning of the board, so the records that matter most for the purpose the card was filed for — the OPEN cards a suspension destroys (共享身份的限流纪律不存在:一次限流信号约束的是「身份」不是「客户端」,而规矩只说了不要重试 —— 2026-09-10 全 fleet 停摆事故 #17374 F3: branches survive, records do not) — come last. At ~405 numbers per 800-request run and four scheduled runs a day, the open set (598 open issues at 13:5xZ + open PRs) is days away from being archived.
  • .github/workflows/board-snapshot.yml schedules 37 1,7,13,19 * * * — copied from the half-state patrol's cadence, which is the SAME minute. Both run under the repository's GITHUB_TOKEN, whose rate limit is per repository per hour (1,000 requests), so a snapshot run that spends 800 leaves the patrol its remainder in the same window (the 13:37 patrol run's outcome is the first data point — read it before choosing the offset).

Deliverable

  1. Open first. The first (and any resumed-first) walk archives state=open issues and PRs completely before it starts the closed history; incremental runs (a since from a previous manifest) keep the single since walk. State the order in the manifest (walk_phase or equivalent) so a reader can tell "open set complete, history resuming" from "still in the open set". Keep the page-walk rule (short page ends the walk; re-anchor on the last row) and the resume cursor semantics.
  2. Cron offset. Move the schedule off the patrol's minute and hour set — e.g. 7 4,10,16,22 * * * — so the two standing callers never share a token hour; keep four runs a day and the workflow_dispatch entry.
  3. Budget statement. The workflow header documents the shared per-repo GITHUB_TOKEN hour and which other workflows spend it (the patrol, this one), with the per-run cap (800) chosen against it. ⛔ No retry loop, no cap raise.
  4. Self-test cases for the open-first ordering and the phase field; the offline fixtures cover a first run whose open set does not fit one budget (the open set resumes before the history starts).

Acceptance

  • A workflow_dispatch run after landing (or the next scheduled run) reports the open set complete in its manifest (issues_open = the repo's open_issues_count minus open PRs at that stamp, pulls_open = the open PR count) before any closed record newer than the cursor is added; the count check turns from pending to a verdict once the open set is complete, or the manifest says exactly why not.
  • Negative control: the incremental path (a manifest with next_since) is unchanged — an identical re-run still writes nothing.
  • The patrol's next scheduled run after the offset lands is green and its anchor's Swept line advances (the standing caller was not starved).

Governing text

#17390 (the card: what the archive is for), #17374 F3/F4 (which records a suspension destroys), the one-board rule (the archive is read-only; nothing here adds a write path to GitHub).

Dedup

Lane titles at 13:5xZ: #17390 (closed, landed — the tool), #17374 (the incident); no card names the walk order or the cron collision. Nearest: the half-state patrol's own header on GITHUB_TOKEN budget (its H-rows read the board four times a day).


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions