Wren's redteam blocker on #3329: two in-flight replies with the same
author/content/root are semantically indistinguishable to
isMatchingPendingMessage, so under the ordering
echo1 -> success1 -> echo2 -> success2 the second echo claimed the
FIRST send's already-consumed localKey, and the localKey-keyed dedupe
then evicted the first confirmed reply — an accepted user message
silently deleted from the pane.
reconcileIncomingMessage now resolves the incoming event's render key
ownership-aware (resolveIncomingLocalKey):
1. a confirmed row with the same id already owns a key -> inherit it,
never re-match a pending;
2. a caller-supplied localKey (onSuccess binding) is honored only if no
OTHER confirmed row owns it — if an echo claimed that pending first,
fall through and claim a remaining pending instead;
3. otherwise claim the first semantically matching pending row.
Pending and confirmed rows never share a key (claiming a pending
removes it in the same merge), so a claimed key can never evict a
confirmed row.
Regression: concurrent-identical-replies ordering matrix over all 4!
echo/success interleavings, asserting both accepted events survive with
distinct render keys and no pending residue. Proven red against the
previous merge logic (stash-verified) and green with the fix. Full
desktop unit suite 3728/3728; both thread-liveness Playwright smoke
specs pass.
Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
6c3d472ffb