Repository navigation
fix(eve): send optimistic messages without crypto.randomUUID - #5417
Merged
AndrewBarba merged 1 commit intoOct 27, 2026
Merged
AndrewBarba merged 1 commit into
AndrewBarba merged 1 commit into
Conversation
Browsers expose crypto.randomUUID only in secure contexts. Restore the local sequence fallback that #4855 dropped so SessionStore.send() works on plain-HTTP origins, and remove the expected-failure marker from the #5415 regression. Co-authored-by: ruiconti <1834568+ruiconti@users.noreply.github.com>
roboeve
Bot
added
the
c1
3 tasks done
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #5415
Stacked on #5416, which pins the bug as an expected failure.
Summary
Browsers expose
crypto.randomUUIDonly in secure contexts. On a plain-HTTP origin that is notlocalhost,OptimisticMessageSubmissions.submit()called it directly, so everySessionStore.send()threwTypeError: crypto.randomUUID is not a functionbefore the message POST. This breaksuseEveAgentsends in React, Vue, and Svelte for, say, a dev server opened from a phone over a LAN IP.The id only correlates a local echo with its delivery, so it needs to be unique within the page, not a UUID. This restores what
createSubmissionId()did before #4855: usecrypto.randomUUID()when the browser exposes it, otherwise a module-levelsubmission_<n>sequence. Secure contexts keep UUIDs, as today.Regressed in: #4855 (
4a4951ef5, first ineve@0.84.0).Alternative to weigh: the reporter suggested building a UUID v4 from
crypto.getRandomValues()for the fallback. That keeps ids unique across page loads, which matters only if an app persistsmessage.idof its own user messages; the sequence matches pre-0.84 behavior with less code.Validation
c9adc04f8):sends where crypto.randomUUID is not exposed, as on a plain-HTTP originfails withTypeError: crypto.randomUUID is not a functionatoptimistic-message-submissions.ts:26, pinned withit.fails(73 passed | 1 expected fail).pnpm --filter eve exec vitest run --config vitest.unit.config.ts src/client/session-store.test.tspasses74/74. The test sends two messages with onlygetRandomValuesoncryptoand asserts both POSTs and two distinct echoes.vitest.unit.config.tsoversrc/client(229 passed) andsrc/react src/vue src/svelte(86 passed).tsc -p packages/eve/tsconfig.json --noEmit,pnpm guard:invariants,oxfmt --check, andoxlinton the changed files.Review rating: c1, restores the pre-#4855 fallback with focused proof, but the reviewer may prefer a
getRandomValuesUUID over the local sequence since the id becomes the publicmessage.id.