Repository navigation
Conversation
Switching away right after a send could leave the optimistic user row in the live cache under its temporary id; if the user_message_persisted reconcile was missed, reselecting the session merged it beside the durable echo of the same prompt and the question appeared twice (vastsa#1308). mergeLiveSessionMessages now grants each durable completed user row one collapse credit: an orphan live user row with equal text consumes one credit and is dropped. A genuinely repeated prompt stays visible because two sends persist two durable rows while each live orphan only consumes one credit. Validated: session-transcript tests 15/15, session-transcript-updates and empty-read suites 10/10; the remaining desktop tsc storage errors reproduce on the pristine main checkout and are unrelated baseline noise.
|
Thanks for reproducing and tackling #1308. The content-credit fallback can also hide a legitimate new prompt: optimisticUserMessage() creates user rows with status "complete", while isInFlightMessage() only exempts "streaming"/running rows. If durable history already contains an identical earlier prompt, a newly submitted optimistic prompt with that text has no durable ID and can consume a credit, so the just-sent prompt disappears during the merge. The added repeated-text test has two durable sends; it does not cover one old durable prompt plus a distinct newly optimistic prompt with the same text. Please constrain the collapse to the actual persisted echo, with a regression test for that case. As written this can hide real user input, so it is not safe to merge; the branch also needs the latest main. Thanks for the work. |
|
Thanks for the original contribution. The fix has been completed and merged through #1340: missed prompt echoes now match only the same prompt using the optimistic message identity and a bounded timestamp window, so older or unrelated identical text cannot hide a new prompt. I’m closing this superseded PR. |
|
Superseded by merged PR #1340. Thanks again for the contribution. |
Review on vastsa#1334 flagged that optimistic rows carry status "complete", so the in-flight exemption cannot protect a fresh prompt: if an earlier durable prompt has the same text, the newly submitted optimistic row had no durable id and could consume its credit, hiding the just-sent prompt during the merge. Each durable user row's credit is now only payable to orphan rows that do not postdate the durable page's newest user row. A persisted echo was created no later than the page; a just-sent prompt is strictly newer and keeps its row. Also removes a leftover duplicate credit path in the final live-only loop that bypassed the guarded push(). Validated: session-transcript suites 26/26 (incl. the new regression covering one old durable prompt plus a distinct fresh prompt with the same text).
|
Pushed 8edb8f8 addressing the review point: A just-sent prompt can no longer consume an older echo's credit. Optimistic rows carry status Also removed a leftover duplicate credit-consumption path in the final live-only loop that bypassed the guarded New regression test covers exactly that scenario: one old durable prompt plus a distinct newly-submitted optimistic prompt with the same text — the fresh row survives. Full suite: 26/26 across session-transcript, -updates, and -empty-read. Rebased check: the branch already contains the latest |
Problem
After sending a prompt, switching away and back could show the same question twice (issue #1308, repro confirmed by the reporter: 回答完切换会话再切回能复现).
Root cause: the optimistic user row lives in the renderer transcript cache under its temporary id. The
user_message_persistedreconcile event re-keys it to the durable id, but if that reconcile is missed (session switched away during dispatch), the orphan row survives with the temporary id. Reselecting the session merges the durable page with the live cache and the id-based merge cannot collapse the two rows of the same prompt.Fix
mergeLiveSessionMessagesgrants each durable completed user row one collapse credit keyed by text: an orphan live user row (no durable id match, not in-flight) with equal text consumes one credit and is dropped. A genuinely repeated prompt stays visible because two real sends persist two durable rows while each live orphan only consumes one credit.Content-equality is only used as a fallback for live-only rows; id-based dedupe remains the primary mechanism, and the credit accounting keeps legitimate repeated prompts intact.
Validation
session-transcript.test.mjs15/15 (incl. two new tests: orphan collapses into its durable echo; genuinely repeated prompt survives the merge)session-transcript-updates+session-transcript-empty-read10/10tsc --noEmit: the only remaining errors (storage/live-voice) reproduce on the pristine main checkout and are unrelated baseline noiseFixes #1308