From 5afdc43be4d2cc0c99beb8ab87b366b3999e9503 Mon Sep 17 00:00:00 2001 From: hshum Date: Sat, 30 May 2026 16:38:38 -0700 Subject: [PATCH] =?UTF-8?q?fix(scratchnode):=20never=20silently=20drop=20a?= =?UTF-8?q?=20cold-load=20send=20=E2=80=94=20queue=20until=20the=20live=20?= =?UTF-8?q?room=20is=20ready?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PR B of the /ask launch-readiness sprint. Root cause (found during PR #443 live verification): in home-v5.html the Convex- routing send override is installed only AFTER the async init — lazy-loading the browser client from esm.sh, then `await joinEvent`. Until that completes, window.sendComposerMessage is still the prototype-only handler: it clears the composer and renders locally but NEVER persists to Convex. A public chat / `/ask` fired in that cold-load window is silently lost — the user believes it sent. This is exactly the first-send failure observed live (it was NOT an Enter-key bug, and NOT the member-row race — the not_joined auto-retry already covers that). Fix (additive, frontend-only): - Install an early queueing shim BEFORE the client-load + join awaits. Public sends are buffered into window._sn_pendingSends (not lost); the composer clears and shows a "Connecting to live room…" hint. Private notes still pass straight to the prototype handler. - The real Convex override drains the queue the moment it installs — replaying each buffered draft through the full sendMessage → askAgent path, in order. - If init fails (client load or join), _sn_failPendingSends restores the most recent un-sent draft to the composer + toasts, instead of dropping it. Verification: all 4 inline