fix(tui): redo and child session ordering across id wrap

[mdrkrg]

Issue for this PR

Closes #42583

Related: #38787, #42589, #39806, #42461

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Message and session IDs contain a time field that wraps around every ~795 days. After a wrap, comparing IDs as strings no longer matches their real order in time.

Two places in the TUI still compared IDs as strings:

• Redo after revert looked for the next user message by ID, which can pick an old message after a wrap. It now finds the next user message by its position in the list (the message list is kept in time order).
• Child session lists were sorted by ID, so a newer session could show up after older ones. They are now sorted by last activity, newest first.

Also added a test making sure trimSessions keeps its output ordered by ID, since the app looks sessions up in that list by ID.

This follows up on #40991/#40990, which removed the same kind of ID comparison on the server.

How did you verify your code works?

• bun test test/util/ in packages/tui
• App global-sync tests pass
• bun typecheck clean in new code

Screenshots / recordings

None

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

I found a related PR, though it's in a different component:

Related PR:

• fix(session): make message ordering robust to ID wrap #39806 - fix(session): make message ordering robust to ID wrap
  • This PR addresses the same ID wrap problem but on the server side for message ordering. PR fix(tui): redo and child session ordering across id wrap #42590 is the complementary client-side TUI fix.

Note: This is listed in the PR description as a related issue (Related: #38787, #42589, #39806, #42461), so it's not a duplicate but rather a complementary fix to the same underlying problem.

No duplicate PRs found

[mdrkrg]

Root cause

packages/opencode/src/id/id.ts:

let now = BigInt(currentTimestamp) * BigInt(0x1000) + BigInt(counter)
now = direction === "descending" ? ~now : now

const timeBytes = Buffer.alloc(6)          // <-- only 48 bits stored
for (let i = 0; i < 6; i++) {
  timeBytes[i] = Number((now >> BigInt(40 - 8 * i)) & BigInt(0xff))
}

return prefix + "_" + timeBytes.toString("hex") + randomBase62(LENGTH - 12)

• now = Date.now() * 0x1000 + counter needs ~53 bits, but only the low 48
  bits are kept. The stored value is effectively
  (Date.now() mod 2^36) * 0x1000 + counter.

• 2^36 ms = 68,719,476,736 ms ≈ 795.4 days ≈ 2.18 years. Whenever
  Date.now() crosses an integer multiple of 2^36, the ID "clock" resets:
  IDs go from ...ffff... back to ...0000....

• The first wrap since 1970 that users will hit is k = 26, i.e.
  26 * 2^36 ms ≈ 1,786,706,395,136 ms (mid-2026).

The ID format is unchanged in this PR (still wraps every ~795 days), this is tracked in #39806

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Scope: fixes redo ("next user message after revert point") and child-session ordering, which previously relied on lexicographic message/session ID comparison — broken because the 48-bit time prefix in IDs wraps (~every 795 days), making fresh msg_0000… IDs sort below older msg_ff42… ones.

• This is the correct way to fix ID-wrap ordering bugs (contrast with approaches that keep comparing IDs numerically — fixed-width hex compares identically either way): nextUserMessageAfter switches to array position over the chronologically-ordered list, and child sessions sort by time.updated ?? time.created with id only as a final deterministic tiebreak.
• The doc comments state the caller's obligation (list must be chronologically ordered) — important since nextUserMessageAfter silently returns undefined-ish results on an unsorted list; worth knowing sync.data.message[...] maintains that invariant.
• The new session-trim test pins that store.session remains id-string-ordered for Binary.search consumers — good documentation of an existing contract, though note that contract itself becomes semantically odd across a wrap (Binary.search by id finds positions, not recency); fine as long as consumers only need lookup-by-id.
• Tests directly encode the wraparound fixture (pre-wrap/post-wrap ids) and assert the naive comparison picks the wrong message while the helper picks the right one — exactly the regression proof you want.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.