Repository navigation
pm-stack(aggregator): board render throws on a lined-up task whose title carries an unsafe-integer ref in a non-first link — titleRefs mints refs parseRef rejects, inFlightBoardItems validates only the first #6210
Description
pm-stack(aggregator): board page render throws when a lined-up task's title carries an unsafe-integer ref in a non-first link — titleRefs mints refs parseRef rejects, inFlightBoardItems validates only the first
Summary
A lined-up (in-flight) task whose own ref is a valid GitHub ref but whose title mentions a ref with a number above Number.MAX_SAFE_INTEGER (e.g. code #99999999999999999999) breaks the whole board page: renderBoard throws ref number is not a safe integer. Assembly survives because only the first link is ever validated; rendering validates every link and throws on the bad one.
Evidence (verified this run, laptop primary @ 04f7869)
pm-stack/aggregator/src/model.ts—parseRefthrowsref number is not a safe integer: <key>for non-safe-integer numbers, and the shared rule (pm-stack(aggregator): validateNewComment/validateNewAction accept ref keys parseRef rejects (GH_REF number unbounded) #4952, comment aboveisValidRef) is that producers must route throughisValidRef;refsInTextdoes (model.ts:480guards every candidate withisValidRef).pm-stack/aggregator/src/sources/live.ts:538titleRefs()scrapes refs from lined-up titles, but its two own regex paths add candidates unguarded: the explicit-refmatchAllat:545and the alias-shorthand#(\d+)matchAllat:555. Neither checksisValidRef.pm-stack/aggregator/src/sources/live.ts:634—inFlightBoardItemscallsparseRef(remainingRefs[0])only to extract the repo of the first remaining ref; every remaining ref is then emitted as a link (links: remainingRefs.map(...)) with no further validation.pm-stack/aggregator/src/render.ts:1506— the orchestrator in-flight card renders every link with unguardedrefUrl(l.ref), which throws viaparseRef.
Probe (real sources via bun, ~/git/fleet/probe-board-render-ref/probe.ts, run in pm-stack/aggregator):
isValidRef huge explicit: false
titleRefs explicit huge: [ "developing-today/code#99999999999999999999" ]
titleRefs alias huge: [ "developing-today/code#99999999999999999999" ]
inFlightBoardItems OK, links: [[{"ref":"developing-today/code#123","relation":"tracks"},{"ref":"developing-today/code#99999999999999999999","relation":"tracks"}]]
renderBoard THREW: Error: ref number is not a safe integer: developing-today/code#99999999999999999999
control renderBoard OK, len 20262
The probe section task has ref: "developing-today/code#123" (valid) and title Fix the thing, follow-up code #99999999999999999999.
Why this is distinct from the sibling filings
- pm-stack(aggregator): one lined-up task with a non-GitHub ref silently deletes the board's whole in-flight lane — inFlightBoardItems parseRef throws into an unlogged catch #6195: a non-GitHub ref as the task's first/own ref throws at
inFlightBoardItems'sparseRef(live.ts:634) during assembly and the lane is silently dropped. Here the first ref is valid, assembly succeeds, and the failure lands later in page rendering, taking down the whole board response rather than one lane. - pm-stack(aggregator): /today render 500s on a lined-up task with a non-GitHub ref — objectives call refUrl unguarded and the section gate never checks linedUp ref #6174: /today objectives calling
refUrlunguarded. Different page, different producer. - pm-stack(aggregator): overview front door throws on a lined-up task with a non-GitHub ref — reconciledInProgress reaches refUrl unguarded #6205 (fixed): overview's
reconciledInProgressreachingrefUrlunguarded. Different derive path. - Session records already show the house precedent for render-time defence:
sessionRecordLinewrapsrefUrlin try/catch so one malformed ref omits only its own link.
Why it matters
Lined-up titles are free text republished by the orchestration pass every run; long digit strings (timestamps, snowflake-ish ids, exaggerated issue numbers in prose) are realistic title content. One such title on one lined-up task currently 500s/breaks the cross-repo WIP board for every viewer until the title scrolls off, and the throw gives no hint which task caused it.
Acceptance criteria
-
titleRefsnever returns a refparseRefrejects: both its explicit-ref and alias-shorthand paths filter throughisValidRef(the pm-stack(aggregator): validateNewComment/validateNewAction accept ref keys parseRef rejects (GH_REF number unbounded) #4952 shared rule), with tests pinning the unsafe-integer forms. - A lined-up task with a valid first ref and an unsafe-integer ref later in its title renders on the board; the invalid ref is omitted (or rendered unlinked), the valid refs stay linked.
- Board rendering cannot be taken down by any single link ref: either assembly guarantees every emitted link
isValidRef, or the render site follows thesessionRecordLinetry/catch precedent. - Regression tests in the aggregator suite (e.g.
test/board-in-flight.test.ts) cover: unsafe refs via the explicitowner/repo#Ntitle form, via the alias#Nshorthand form, and in a non-first link position.
Activity
developing-today commentedon Nov 5, 2026
CODE-1811
dezren39 commentedon Nov 5, 2026
🤖 Agent note · filed
dezren39 commentedon Nov 5, 2026
Queue note: the enqueue command was run twice while capturing its task id (the first call's output was truncated before the id field). The returned task is task 10027 with dedupe key repo-health:v1:triage:developing-today/code:issue:6210; if a second task with the same dedupe key exists, the duplicate should be superseded by its claimant — the packet is identical (hidden_files/packet-6210-triage.json).
103 remaining items
dezren39 commentedon Nov 6, 2026
🤖 Agent note · done (PR opened)
8ac61616-3815-4e7b-b33d-840a3829154atitleRefsnow filters every candidate withisValidRef; PR fix(aggregator): filter invalid title refs #6475 is open and the issue remains open pending merge.git diff --checkpasses. The board-in-flight suite has four unrelated failures on cleanorigin/main(stale openchamber alias expectations; 9 pass / 4 fail), reproduced on this branch..github/workflows/pm-aggregator-tests.ymlis configured with onlyworkflow_dispatch, despite its comments describing PR path filtering.dezren39 commentedon Nov 8, 2026
Partial verification — staying open (2026-11-07 done-task-only audit, tracking: #7016).
Queue task(s) [10027, 10030] were marked done, and some work did land:
No merged change closes this issue's full scope, so the done status is not treated as completion. Remainder re-queued as triage task 11764.
dezren39 commentedon Nov 8, 2026
🤖 Agent note · picked up — triage verdict for task 12493
direct; worked by this lane)main(16d4a724f0).Triage verdict — remainder is exactly one unmerged PR; every acceptance criterion is already covered
Fresh checks this shift:
held,user/owned,do-not-merge,do-not-auto-editabsent).main,titleRefsinpm-stack/aggregator/src/sources/live.tsstill adds explicit-ref and alias-shorthand candidates unguarded — the bug is live. The assembly-side guard from merged PR fix(pm-aggregator): tolerate invalid in-flight refs #6334 is present (inFlightBoardItemsfilters every ref throughisValidRefand logs drops), so emitted links are safe, buttitleRefsitself still violates the pm-stack(aggregator): validateNewComment/validateNewAction accept ref keys parseRef rejects (GH_REF number unbounded) #4952 shared rule this issue cites.clean, 2 files +18/−0, body carriesCloses #6210. That is the whole remainder.has_any_findings: false,has_unresolved_findings: false; no inline Codex findings to disposition.titleRefsnever returns a refparseRefrejects — the PR guards the singleadd()both scrape paths funnel through withisValidRef. ✓titleRefsguard (PR) plusinFlightBoardItems'isValidReffilter (PR fix(pm-aggregator): tolerate invalid in-flight refs #6334, onmain). ✓owner/repo#Nform, the alias#Nshorthand form, and a non-first link position — PR'stitleRefstest pins both forms; itsrenderBoardtest pins the non-first position. ✓main(stale openchamber alias expectations, reproduced by the PR author onorigin/main) — unrelated to this change..github/workflows/pm-aggregator-tests.ymlis dispatch-only) is already filed as issue pm-aggregator-tests workflow: auto triggers BLOCKED on runner strategy (dispatch-only by Drew's ruling 2026-11-05) #6126 (blocked on runner strategy by Drew's 2026-11-05 ruling) — no duplicate follow-up is filed here.Action: merging PR #6475 under the standing merge criteria (verified diff matching intent, Codex clean, mergeable clean, targeted tests passed). Its
Closes #6210closes this issue on merge; this triage task then completes astriagedwith the merge as the landed evidence.developing-today commentedon Nov 8, 2026
🤖 Agent note · done (triaged — remainder merged)
99f326a055989ae3fed5ef0e6f73b95682d19f0cat 2026-11-08T05:35:12Z; theisValidRefguard intitleRefsverified present onmainafter merge; PR fix(aggregator): filter invalid title refs #6475'sCloses #6210closed this issue at 2026-11-08T05:35:14Z. All four acceptance criteria are covered by PR fix(aggregator): filter invalid title refs #6475 + merged PR fix(pm-aggregator): tolerate invalid in-flight refs #6334; the dispatch-only CI workflow gap remains owned by issue pm-aggregator-tests workflow: auto triggers BLOCKED on runner strategy (dispatch-only by Drew's ruling 2026-11-05) #6126.triaged, issue_state closed.