Repository navigation
[finding] the generated shard-timings dataset has no scheduled refresh, and its documented refresh path is unreachable from an agent container #16222
Description
scripts/test-shard-timings.json is GENERATED and nothing refreshes it on a
schedule. Its own provenance.refresh names two manual paths, and both are
weaker than they read:
- "Download all six
test-core-run-summary-N-of-6artifacts from any green
queue build." — measured from an agent container while working CI: the shard-timings file is stale for the CLI package — 672s predicted vs 28m46s measured against a 30-minute timeout, so Test Core shard 1/6 is one slow run from being killed on any PR touching the CLI #16173:
GET /repos/.../actions/artifacts/{id}/zipredirects to
productionresultssa11.blob.core.windows.net, and the session egress policy
answers 403 to CONNECT. The artifacts existed and were unexpired; the
channel is what is missing. Job logs are reachable through the MCP
GitHub tooling, which is how the numbers on CI: the shard-timings file is stale for the CLI package — 672s predicted vs 28m46s measured against a 30-minute timeout, so Test Core shard 1/6 is one slow run from being killed on any PR touching the CLI #16173 were obtained, but the
summary JSON the generator consumes is not printed to a log — only its path
on the runner is. - "Or a local
pnpm exec turbo run test --concurrency=4 --summarize." — a
whole-workspace test run. The agent containers cap a foreground command at
about ten minutes and the shared heavy-verify lock budget is 540s, and
@objectstack/clialone now measures 1231.52s. Not reachable either.
So the refresh is, in practice, maintainer-only and manual, for a file whose
entire design premise is that regenerating it is cheap. It was last measured
2026-08-24; thirteen days later one entry was wrong by 2.69x and a shard was
killed by the 30-minute wall.
Why this is separable from #16173
#16173 gets detection — a per-shard predicted-vs-measured drift check that
reds. Detection tells you the file has rotted; it does not un-rot it, and the
next person to see that red still has to reach a channel that is closed to
agent seats. This card is the prevention half of the question #16173 itself
poses: "Ask what makes it go stale and whether anything refreshes it on a
schedule." #16173 does not answer it and is not expected to.
The shape that looks cheapest, offered as a lead and not a ruling
The download only exists because the regeneration happens somewhere the
summaries are not. Inside a merge_group job the summaries are already on
disk — .turbo/runs/ in the workspace, which is exactly what the existing
upload step publishes. A rollup leg (or a scheduled workflow) that collects the
six shards' summaries in-runner and runs the existing generator needs no
artifact download at all, and could open a PR with the regenerated dataset.
partition-test-shards.mjs --self-test's balance pins today — measured on
#16173, substituting the true CLI weight puts the heaviest single package at
1.54x the mean against a 1.3x bound. That is those pins working as designed, and
it is a decision sitting on #16173, not a defect in the refresh path. Sequencing
matters more than usual here.
Refs: #16173 (the stale-dataset bill, and where these numbers were measured).
Generated by Claude Code
Activity
claude commentedon Sep 7, 2026
Graded by the skills lane seat on the maintainer's direction (2026-09-07, 「同意你的建议，你负责执行派发所有可行的优化」):
domain:devx,tooling,priority:p2,pm:blocked.Blocked-by: #16464
Both halves of this finding are the remedy card #16464 (a scheduled in-runner refresh, dispatched 03:3xZ as flight C2a): the schedule removes the "nothing refreshes it" half, and running where
.turbo/runs/*.jsonalready sits removes the unreachable-path half. Flight C1 on #16173 reproduced the egress denial a second time today (03:2xZ), on a different container. This card closes when #16464's workflow has run its first refresh.Generated by Claude Code
claude commentedon Sep 7, 2026
Blocker cleared, and this card moves to
pm:on-holdrather than back to the queue: #16464's lane MERGED at 09:43:41Z (PR #16498), and this card's deliverable is the PR that lane's first run opens — there is no dev work to dispatch until it exists.Restart-when: the shard-timings refresh lane (
.github/workflows/shard-timings-refresh.yml) opens its first refresh PR — weekly Monday 05:30Z, or sooner on a maintainer'sworkflow_dispatch.Restart-touch: scripts/test-shard-timings.json
Whoever lands that first refresh PR retires this card by hand: the lane's PRs carry
Refsonly, never a closing keyword, because a weekly lane cannot know which cards a given run ought to close.pm:blocked→pm:on-hold,Blocked-by: #16464discharged. Posted by the skills seat (sessionsession_019RfFHiRCSs3JXLK4cwcfox) as its own bookkeeping: it was this seat that parked the card there.Generated by Claude Code
os-steve commentedon Sep 21, 2026
关闭(维护者指令,skills 席 2 代执行;裁决 #202 B)— 2026-09-21T03:43Z
出处三件(
SKILL.md:149 代执行他人指令,评论带出处三件)— 谁的指令:维护者,在本席(domain:skillsseat 2,session_017ETYWqMQD4qMtZzAGovWNi,席位帖 #19287)会话内的真实用户轮次。在哪说:本席会话聊天,2026-09-21,在本席呈交「停放排查」四组清单(全板 165 张停放卡:pm:blocked64 +pm:on-hold101;其中 38 张的停放条件已消失——正文与评论里Blocked-by:/Restart-when:指向的卡或 PR 全部已关或已合)之后。原话(逐字,⛔ 未翻译、未润色):「还有哪些应该解除停放的你一起排查一下」;对四组清单:「同意」。本卡属第二组「条件已消失、但是工具卡 ⇒ 按 #202 B 关闭」:本席于 2026-09-21T03:00Z 机器复核,本卡停放所指向的目标已全部关闭/合并,或其前提已不复存在;而修复落在门禁 / 脚本 / workflow / CI / 席位协议 / PM 工具面,不在产品包——按维护者裁决批次 #202 项 1 字母 B 及其修正「close, never hold」(记录于 #19457):工具卡不带
Unblocks: #N(open 产品卡)或所护已发布面的点名,即关not_planned,⛔ 不转 hold、不定 p3。两条重开条件(任一即可重开进
pm:queue·tooling):① 首行Unblocks: #N,N 为一张 open 的产品卡;② 卡面点名本修复所护的已发布面。卡上已有的测量与分析原样保留,供重开时续用。Generated by Claude Code
chore(ci): refresh the Test Core shard-timings dataset (objectstack-a…
chore(ci): refresh the Test Core shard-timings dataset (objectstack-a…
chore(ci): refresh the Test Core shard-timings dataset (objectstack-a…