[Bug] Chat: "Load earlier" can succeed without adding any rows

[plyflai]

What happens

Clicking Load earlier in Chat can return a successful page while no new rows appear on screen. Clicking it repeatedly looks like the button is simply broken. A browser refresh that replays the same history window can expose the same symptom.

Where

packages/client/ui-chat/src/client/conversation-nodes/message.ts

Cause

The input-message Context id is derived from the producer id:

? { id: String(event.data.id), role: 'start' }

When two append-surface user/message events carry the same producer data.id, both match a single input-message Context as two separate starts. That violates the assembler's unique-start invariant, so the later occurrence is folded away and produces no visible row. Neither symptom requires missing persisted events or a server restart.

Observed evidence

With a long transcript, paging twice produced:

step	anchor elements	Chat text (characters)
initial	193	10,613
after 1 page	401	32,767
after 2 pages	597	41,633

Suggested fix

Use the event's own position for row identity, and keep the producer id for the things that genuinely need it:

? { id: String(event.seq), role: 'start' }

data.id is still required for Inbox correlation and steering classification, so it should stay in the payload — only the Context/row identity needs to change.

Why this cannot be a plugin

The conversation.chat.node slots render nodes, but they do not let a plugin change how node identity is computed, and there is no public seam for registering or overriding a ConversationNodeDefinition. So this appears to need a change inside ui-chat.

Process note

Issues are disabled on this repo and CONTRIBUTING.md states external pull requests are not accepted, so I am posting here as instructed. Sorry if this is the wrong category — happy to move it.

[PerryLink]

Confirmed, with one mechanism correction that doesn't change your conclusion.

The identity derivation is as you quoted, packages/client/ui-chat/src/client/conversation-nodes/message.ts:47-50:

match: event => event.type === 'user/message'
    && isAppendSurfaceEvent(event)
    && !isCompactionCheckpoint(event)
    ? { id: String(event.data.id), role: 'start' }
    : null,

So two append-surface user/message events sharing a producer data.id produce two start matches for one input-message context key — that part is exact.

Drift: the assembler doesn't "fold" the later start; it throws an invariant error. packages/client/ui-conversation/src/client/conversation/assembler.ts:512-513:

if (role === 'start' && context?.start !== undefined) {
  throw new Error(`conversation Context ${key} received more than one start Match`)

(the batch path at :567-570 has the same throw). The silent "success" comes from the caller: packages/api/session-controller/src/client/sessions/session.ts:391-407 (loadOlder) catches non-RemoteFailure errors with only console.error('[session-controller] loadOlder failed:', error) (:401). Worse, prependWindow advances baseSeq/hasMore before subscribers run (session.ts:686-689), so the failed page is still marked consumed — repeated clicks keep skipping forward with no rows, matching your measured table.

Your suggested fix is sound and consistent with the file: event.seq is already the per-node identity (seq: event.seq at message.ts:58, :72, :79), so { id: String(event.seq), role: 'start' } gives every event a unique context key while data.id remains in the payload for the inbox claim at :66-67. Your "cannot be a plugin" conclusion also checks out: the definition registry rejects duplicate keys (definition-registry.ts:46-49), and ui-chat already owns input-message, so a plugin can't override the match logic.

Two notes: (1) the refresh symptom you mention shares a shape with #6954 — the same duplicate pair in the opening window would throw through doOpen's non-RemoteFailure rethrow at session.ts:607, leaving no error surface. (2) Not verified from source: where the duplicate producer data.ids originate — that part rests on your long-transcript evidence.

If you can share the two colliding events' full payloads (type/source/id/seq) from a session log, that would pin down the producer path.