[hieu-lee]

Problem

Selecting an OpenCode fork/revert boundary filters, sorts and maps the later provider turns even though the result is one native message ID. The helper takes O(N log N) time and O(N) auxiliary space.

Solution

Keep the first selected-turn lookup, then scan for the lowest eligible later ordinal using scalar state. Strictly smaller ordinals replace the winner, preserving stable first-wins ties; missing native references and empty native IDs retain their existing behavior. Helper work becomes O(N) time and O(1) auxiliary space, with no input mutation or caller change.

Validation (tests written before production code):

• The existing adapter test was extended before implementation. All 43 owning adapter tests pass, including actual fork/revert runtime paths.
• Actual-source differential proof passes 23,502 complete-result comparisons, frozen-input checks and linear operation bounds up to 65,536 turns.
• vp run check:changed a21d788752695764028e6d26ba924f3963e05806 --concurrency 2 passes: format, lint, Knip, 10 affected/dependent typechecks and 45 selected tests.
• One fresh batch of three independent Codex reviewers returned clean on the final diff.

Full overlapping PR diffs were inspected; none changes this boundary helper. Related fork-call-path work: #15777. This is a small algorithmic fix in an existing helper, with no feature, permission, provider protocol or contract change; no prior maintainer approval is claimed. To reproduce the unnecessary work, provide an unordered history with many later native turns: the previous implementation sorts the full filtered history before returning only its first usable ID. Operation bounds and source-level space analysis are not a wall-clock, allocated-byte or end-to-end latency claim.

TLDR

complexity-opencode.mp4

Model: GPT-6.1 Sol. Harness: Codex in T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at f94736b

Macroscope's review found this PR approvable — Optimizes OpenCode fork and rewind boundary selection by replacing sorting with a constant-space linear scan. Existing boundary behavior and external calls remain unchanged, with no new operational exposure.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The boundary selection function now scans later provider turns and selects the native ID from the turn with the lowest eligible ordinal. Expanded tests cover ordering, ties, missing and synthetic turns, null and empty IDs, empty history, and input immutability.

Changes: Provider turn boundary

Layer / File(s)	Summary
Select and verify the boundary packages/provider-opencode/src/server/adapter.ts, packages/provider-opencode/src/server/adapter.test.ts	The function selects the usable native ID with the lowest ordinal among later turns. Tests cover ordinal ties, skipped turns and IDs, empty history, and unchanged input turns.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Refactor

Suggested reviewers: juliusmarminge, saphid

Merge Risk: Minimal · up to f9473

The boundary selection is intended to preserve existing behavior, and no merge-blocking risk is established.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "perf(opencode): select fork boundaries without sorting" matches the main change: the fork/revert boundary helper now scans for the lowest eligible ordinal instead of filtering, sorting and …
Description check		The description follows the template's main sections (Problem, Change, Scope and approval, Verification) and is detailed. Problem and Solution cover the O(N log N) to O(N) change and preserved behavio…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title "perf(opencode): select fork boundaries without sorting" matches the main change: the fork/revert boundary helper now scans for the lowest eligible ordinal instead of filtering, sorting and mapping the later provider turns. It follows the conventional commit style of the repository template and is concise and specific.

Full details: Description check

Explanation

The description follows the template's main sections (Problem, Change, Scope and approval, Verification) and is detailed. Problem and Solution cover the O(N log N) to O(N) change and preserved behavior. The author states that no prior maintainer approval is claimed and gives a reason for the small fix. Verification lists focused tests, a differential proof, and a check:changed run with results, and notes what the bounds do not prove. The template's 'Change' heading is labeled 'Solution' and there is no UI section, which is acceptable here. The description also lacks an explicit reproduction step in the Problem section, but it does describe how to reproduce the extra work.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: a21d788
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: ac681cdf-49e9-451d-b83b-7350d2e56a87

Commits

Reviewing files that changed from the base of the PR and between a21d788 and f94736b.

Files selected for processing: 2

• packages/provider-opencode/src/server/adapter.test.ts
• packages/provider-opencode/src/server/adapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.

[hieu-lee]

@juliusmarminge could you review this when you have a moment?

Written by Claude Sonnet 5.5 via Claude Code in T3 Code.

[juliusmarminge]

Thanks for this. Before a bug fix is taken further, the bug is reproduced on current main, and here it did not appear.

We measured this on main at dae8d6f. Timed on its own with shuffled histories, the current boundary selection takes about 0.08 ms at 1,000 turns, under 1 ms at 10,000, and roughly 2.5 to 4 ms at 65,536. A linear scan stays near 0.1 ms even at the largest size, so the extra work you describe is real.

We then forked a real OpenCode thread five times from the web app on the same commit. The adapter's fork step took 37 to 105 ms, and almost all of that was OpenCode's own fork call. Everything else in the adapter, boundary selection included, took about 1 ms, and every fork kept the right history. Even at 65,536 turns the sort would add about 3 ms to an operation that already takes 40 to 100 ms in OpenCode, so we couldn't find a fork or rewind that is noticeably slow because of it.

We're closing this as a change with no user-visible effect rather than a fix. If you have a real thread where forking or rewinding is slow, please open an issue with the history size and timings and we'll look again.

Closing this pull request. If it still happens for you, please open an issue with the exact steps, what you see, and the version and platform you are on; a fix is picked up from there.