[polylane]

Fixes: Thread Transfer Report fails on PRs that also have an upstream pull request

The Thread Transfer Report job failed whenever a pull request's head commit was also proposed to the upstream repository. The publisher read the first pull request in the CI run payload without checking which repository owned it, so it asked this repository for a number that does not exist there and stopped before updating the report comment. It now keeps only the pull requests that belong to this repository.

flowchart TD
  A["CI run payload: pull_requests"] --> B{"base repo is this repository?"}
  B -->|"no: upstream PR 22428"| C["observed before fix: lookup PR 22428 in uuid-rocks/t3code"]
  C --> D["404, job fails, comment not updated"]
  B -->|"yes: this repository's PR 2"| E["proposed fix: lookup PR 2"]
  E --> F["report comment updated on PR 2"]

Loading

Why this fix

The failing run's payload lists two pull requests for head commit c7474ab: upstream pingdotgg#22428 first, this repository's #2 second. The publisher used the first entry against this repository and the API answered 404. Earlier runs succeeded and updated the comment on #2, so #2 is the intended target, and the job's token cannot write to the upstream repository. Keeping only entries whose base repository is this one lets the existing commit-association lookup resolve the right pull request.

Fix walkthrough

Watch the fix explained (1:26). Recorded for commit 283cf48cf3d7ad851e6e510b3bd1baa49f2dbd83.

Out of scope

• The same publisher script exists in the upstream pingdotgg/t3code repository with identical content. That repository is not connected here, so this change does not reach it.

Causal chain

• Signal (alert): GitHub Actions workflow "Thread Transfer Report" run perf replay r05-b: revert 08af12da4 (packages/shared small fix + mobile test) #22 (attempt 1) concluded failure on main at 67c0fc0
• Surfacing site: github repository uuid-rocks/t3code at uuid-rocks/t3code:.github/scripts/thread-transfer-report.cjs#resolve
• Mechanism: The workflow_run payload of CI run 39469918610 lists the upstream pull request ci(release): Make Windows arm64 CI job 50% faster pingdotgg/t3code#22428 first and this repository's pull request ci(release): build Windows arm64 on Linux, verify it on windows-11-arm #2 second, because both share head branch ci/win-arm-linux-build-pr and head SHA c7474ab. resolve() takes pull_requests[0].number (22428) and calls github.rest.pulls.get with owner/repo uuid-rocks/t3code, which has no pull request 22428, so the API returns 404 and the step throws.
• Producer: Thread Transfer Report publisher script in uuid-rocks/t3code, at uuid-rocks/t3code:.github/scripts/thread-transfer-report.cjs#resolve
• Trigger: Upstream pull request ci(release): Make Windows arm64 CI job 50% faster pingdotgg/t3code#22428 was created at 2026-10-20T17:50:12Z for the fork branch ci/win-arm-linux-build-pr, adding a foreign pull request entry ahead of this repository's own pull request in the CI run payload.
• Cadence check: Runs ci(release): Windows arm64 desktop build ~37% faster on windows-11-arm #1 through perf replay r05-a: revert 08af12da4 (packages/shared small fix + mobile test) #21 succeeded on the same commit 67c0fc0 and updated the comment on pull request ci(release): build Windows arm64 on Linux, verify it on windows-11-arm #2 at 17:42:17Z; run perf replay r05-b: revert 08af12da4 (packages/shared small fix + mobile test) #22 failed at 17:54:10Z, the first run after the upstream pull request appeared at 17:50:12Z.
• Blast radius: unknown other resource(s), unknown other tenant(s); data at risk: none named
• Producer evidence:
  • thread-transfer-report.cjs line 245 takes source.pull_requests?.[0]?.number without checking the entry's base repository
  • thread-transfer-report.cjs line 288 issues pulls.get in context.repo with that number and does not tolerate a 404
  • Job log for run 39470082851: HttpError: Not Found for https://api.github.com/repos/uuid-rocks/t3code/pulls/22428 at line 288
  • Run 39469918610 payload: pull_requests [22428 base pingdotgg/t3code, 2 base uuid-rocks/t3code]

2 files changed (+124/-1)

• .github/scripts/thread-transfer-report.cjs: modified, +18/-1
• .github/scripts/thread-transfer-report.test.cjs: modified, +106/-0

Repository lint: pnpm run lint (declared in package.json) fails over the whole repository (the declared target takes no file arguments), so the failure is not attributed to this change and did not block it; run it before merging.

Lint output

file:///root/.local/share/pnpm/.tools/pnpm/11.10.0/node_modules/pnpm/dist/pnpm.mjs:40380:23)
    at callBoundExeca (file:///root/.local/share/pnpm/.tools/pnpm/11.10.0/node_modules/pnpm/dist/pnpm.mjs:42908:23)
    at boundExeca (file:///root/.local/share/pnpm/.tools/pnpm/11.10.0/node_modules/pnpm/dist/pnpm.mjs:42885:49)
    at sync (file:///root/.local/share/pnpm/.tools/pnpm/11.10.0/node_modules/pnpm/dist/pnpm.mjs:43040:14)
    at runPnpmCli (file:///root/.local/share/pnpm/.tools/pnpm/11.10.0/node_modules/pnpm/dist/pnpm.mjs:247665:5)
    at runDepsStatusCheck (file:///root/.local/share/pnpm/.tools/pnpm/11.10.0/node_modules/pnpm/dist/pnpm.mjs:249406:7)
<--- Last few GCs --->

[1689:0x39e18000]   108219 ms: Scavenge 2003.7 (2018.7) -> 1998.7 (2018.7) MB, pooled: 0 MB, 6.20 / 0.01 ms  (average mu = 0.327, current mu = 0.323) task; 
[1689:0x39e18000]   109552 ms: Mark-Compact (reduce) 2009.3 (2022.7) -> 1980.1 (1987.6) MB, pooled: 0 MB, 95.33 / 0.01 ms  (+ 978.0 ms in 248 steps since start of marking, biggest step 13.0 ms, walltime since start of marking 1332 ms) (average mu = 0.349,
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x942e80  [node]
 2: 0x75f71e node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 3: 0xc98c20  [node]
 4: 0xc98d0f  [node]
 5: 0xf3c5e5  [node]
 6: 0xf3c612  [node]
 7: 0xf3c90a  [node]
 8: 0xf4d60a  [node]
 9: 0xf519b0  [node]
10: 0x19ef441  [node]

---

Generated by Polylane. You can ask follow-ups by mentioning @polylane in a comment.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.8 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	1	—	8	✅
Claude	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	21.2 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: 283cf48 · Source CI: failure

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[polylane]

This pull request is waiting on a decision: merge it if the change is still wanted, or close it if the fix is no longer needed. Either one settles it.

It was opened on 2026-10-20 and has had no new activity for a week. If nothing happens on it within a week, Polylane closes it and keeps the branch, so reopening it brings the change back exactly as it stands.

@jahands, the change touches what you own, so the review is with you.

[polylane]

This pull request is closing without a merge, and nothing is lost: the branch polylane/autofix/yholhvkgqtqs stays in place, reopening the pull request brings the change back exactly as it stands, and Polylane will propose a fresh fix if the problem returns.

It was opened on 2026-10-20, Polylane reminded the maintainers about it on 2026-10-30, and nothing has happened on it since.

@jahands, you were asked to review this pull request; reopening it puts it back on your list.