Skip to content

chore(upstream): adopt the 2026-08-20 T3 Code batch - #62

Merged
rynfar merged 10 commits into
pylonfrom
upstream/2026-08-20-batch
Aug 20, 2026
Merged

chore(upstream): adopt the 2026-08-20 T3 Code batch#62
rynfar merged 10 commits into
pylonfrom
upstream/2026-08-20-batch

Conversation

@rynfar

@rynfar rynfar commented Aug 20, 2026

Copy link
Copy Markdown
Collaborator

Adopts 6 of 8 upstream commits from a850895f..beab6886f. Two are deferred as DEF-5, with reasoning below.

#7602 closes the canary follow-up the second 2026-08-19 batch opened. @clerk/electron goes to stable 0.0.34, passkeys back to 0.0.3, and all four platform-specific native canary entries leave minimumReleaseAgeExclude. Verified against the exact condition the ledger recorded — npm view @clerk/electron dist-tags now reports latest: 0.0.34. Pylon stops shipping prerelease native binaries, so the "only darwin-arm64 was ever exercised" risk retires with it.

Also in: #7595 (usage hourly ordering), #6222 (terminal pane gutter), #7633 (test assertions), #7642 (Open VSX theme imports), #7151 (tool lifecycle identity).

A conflict resolution leaked a secret, and Pylon's own test caught it

Adopting #7151 as a plain union put upstream's unconditional toolCallId: event.itemId beside Pylon's primeAgentTool gating rather than behind it. A Prime tool's itemId is a canonical filesystem path — exactly the native detail that gating exists to withhold — so the projection began carrying canonical-prime-tool-/private/native-secret. ProviderRuntimeIngestion.test.ts asserts that string must not appear and failed immediately. Fixed in 0d70d9aec, along with two other gaps in the same resolution (upstream's status for non-Prime tools, and data on tool.started).

#7150 and #7152 are deferred, not skipped

#7150 rewrites 1084 lines of ChatComposer.tsx — 50 Pylon commits, 4837 lines against upstream's 2824. I made a full pass: classified all 11 conflict blocks, traced each one's provenance, and resolved them individually — keeping Pylon's settle loop (ce5371d41, which fixed a bug upstream's approach reintroduces), resolvedRuntimeMode, the 169 lines of Quick question and session-resource controls, and the ThreadHandoffTab wrapper, while taking upstream's drawer measurement and its 335-line drawer structure.

It compiled to 8 JSX errors. Upstream flattens the fragment and nested provider-frame divs into a single <form>, so its added tree cannot be hosted by Pylon's layers — the two are ends of one restructure. #7152 then conflicts on MessagesTimeline because it genuinely depends on #7150.

That needs the composer rebuilt on upstream's structure with Pylon's features grafted back, which is its own piece of work rather than a merge. Registered as DEF-5 with the full graft list.

Verification

  • 115 tests across the 4 changed test files, 0 failures. Typecheck clean across 7 packages, each confirmed to have actually run.
  • Live in the web client against seeded real data: pairing, thread view, the Usage page and its "Hourly cost by provider" chart, Settings → Appearance with the theme list and Import theme. No error surfaces.
  • Not verified: #7595's chronological hour ordering. The chart exposes no hour labels to the DOM, so ordering could not be asserted from the browser — said plainly rather than implied.
  • An xhigh review returned 13 findings. Two fixed in 2cf95d544: a status ternary whose arms were provably identical, and the missing test for a dedupe branch this batch widened.

Worth knowing, recorded in the ledger

#7151 widened the snapshot dedupe — toolLifecycleIdentity now prefers a payload-level toolCallId, which that commit sets on every tool activity. The clients read only data.toolCallId, so they can't mirror it: in-flight rows with differing details render live and collapse after a reload. The new test pins the behavior; whether it's the behavior Pylon wants is a separate call. Four more findings (unprojected tool.started data, a separator-less identity join, the relaxed zip-bomb ceiling in #7642, an unreachable Past-24h empty state) are in the ledger.

Model: Claude Opus 5 in Pylon.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith with what you need. Autofix is disabled.

lgwacker and others added 9 commits August 20, 2026 11:12
…595)

(cherry picked from commit 62654d279fcdd910bb755e106dfd51bc8940c263)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 105cd5e0c57ab8b6df3bd8af5b534a5bc682fdce)
(cherry picked from commit 9027d62679c6669d8e45e2e419b311ec8dfdaa4f)
Co-authored-by: t3-code[bot] <269035359+t3-code[bot]@users.noreply.github.com>
(cherry picked from commit f708f63fa9bcd7e51f1f62531f6f9ed966b71807)
Co-authored-by: t3-code[bot] <269035359+t3-code[bot]@users.noreply.github.com>
Co-authored-by: maria <254055478+maria-rcks@users.noreply.github.com>
(cherry picked from commit beab6886f45bf42906d0bd01aefe5dfe9e66a867)
(cherry picked from commit b2e2ccfdb462c45a8de394ff9ff0f58a4a689900)
Adopting #7151 as a plain union added upstream's `toolCallId: event.itemId`
unconditionally, next to Pylon's `primeAgentTool` gating rather than behind it.
A Prime tool's itemId is a canonical filesystem path, which is exactly the
native detail that gating exists to withhold — so the projection began carrying
`canonical-prime-tool-/private/native-secret`. Pylon's own test asserts that
string must not appear, and caught it.

`toolCallId` now sits behind the same gate. Two further gaps in the same
resolution are closed while here: upstream's unconditional `status` is kept for
non-Prime tools alongside Pylon's derived Prime status, and `tool.started`
regains the `data` spread upstream added.

115 tests across the four changed files pass, including both that failed.
…dupe

Two findings from an xhigh review of this batch.

The Prime/non-Prime status ternary I added while gating `toolCallId` had two
behaviorally identical arms: `toolLifecycleActivityStatus` already returns `{}`
when `payload.status` is undefined, and `RuntimeItemStatus` is a non-empty
union, so the falsy check could never differ. Both sites collapse to the helper.

`#7151` also widened the snapshot dedupe: `toolLifecycleIdentity` now prefers a
payload-level `toolCallId`, and that commit sets one on every tool activity, so
identity is `id:<itemId>` where it used to fall back to itemType/title/detail.
No test exercised the new branch — the fixture only ever set `data.toolCallId`.
Added one that pins it, including the consequence: updates whose detail differs
from the completion's now collapse into it, which the clients do not mirror
because they read only `data.toolCallId`.
@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L labels Aug 20, 2026
@github-actions

github-actions Bot commented Aug 20, 2026

Copy link
Copy Markdown

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider Metric Main baseline This PR Impact PR ceiling
Codex Total thread wire 12.6 KiB 13.4 KiB +827 B (+6.4%) 15.1 KiB
Codex Thread snapshot wire 6.3 KiB 6.9 KiB +615 B (+9.6%) 7.3 KiB
Codex Live turn WebSocket wire 6.3 KiB 6.5 KiB +212 B (+3.3%) 7.8 KiB
Codex Live turn WebSocket decoded 51.8 KiB 55.0 KiB +3.2 KiB (+6.1%) 66.4 KiB
Codex Live turn messages 16 16 0 (0.0%) 21
Claude Total thread wire 12.6 KiB 13.5 KiB +877 B (+6.8%) 15.1 KiB
Claude Thread snapshot wire 6.3 KiB 6.9 KiB +627 B (+9.8%) 7.3 KiB
Claude Live turn WebSocket wire 6.3 KiB 6.6 KiB +250 B (+3.9%) 7.8 KiB
Claude Live turn WebSocket decoded 52.7 KiB 55.8 KiB +3.2 KiB (+6.0%) 66.4 KiB
Claude Live turn messages 16 16 0 (0.0%) 21

Baseline: f89e16d · PR result: 4a5f99a · 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: 109.4 KiB
  • Claude decoded thread snapshot: 110.0 KiB

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

@rynfar
rynfar merged commit 5ce9308 into pylon Aug 20, 2026
10 of 11 checks passed
@rynfar
rynfar deleted the upstream/2026-08-20-batch branch August 20, 2026 18:27
rynfar added a commit that referenced this pull request Aug 20, 2026
`pylon` has been red since #62. Adopting #7151 carries the adapter's status
onto every tool lifecycle row, not just Prime's, and this suite asserted the
opposite for `tool.started` and `tool.completed`.

The assertions described the behavior before that commit rather than guarding a
Pylon invariant — the test's subject is that Prime-specific handling does not
leak into non-Prime paths, which still holds — so they follow upstream. The
alternative was re-gating status to Prime only, which contradicts #7151's own
test expecting `status: "inProgress"` on a non-Prime `item.started`; the two
cannot both hold, and staying in step wins where Pylon has no stated reason.

Worth remembering: this was caught by CI, not by me. A targeted run covered
ProviderRuntimeIngestion.test.ts and missed the .activity.test.ts sibling, and
I merged #62 without checking that pylon went green afterwards.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants