fix(session): failed saves degrade to a log line - #72
Merged
Merged
Conversation
…oasts
Session persistence ran as bare fire-and-forget promises, so a rejecting
session:save invoke — e.g. a stale main process that predates the handler
after an update — became an unhandled rejection and toasted "Something
failed" at the user twice per run. All saves now route through a
persistSession helper that catches rejections and { ok: false } results
and writes a warn line to the renderer log instead; the in-memory log
stays authoritative and the run completes normally.
Co-authored-by: Cursor <cursoragent@cursor.com>
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
1 participant
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.
Summary
Fixes the on-screen "Something failed: … No handler registered for 'session:save'" toasts from pre-alpha testing. Root cause of the visible error was a dev app whose main process predates PR5 (restart
npm run devto load the handler) — but the toast spam itself was a real robustness gap: the store firedsaveSessionas barevoidpromises, so any rejection hit the global unhandled-rejection handler.persistSession, which catches both rejections and{ ok: false }results and logs a warn line vialog:rendererinstead of toasting; the in-memory session stays authoritative and runs complete normally.session:saveleaves the completed turns intact, produces zero notices, and logs the failure (146 tests total).Renderer-only — HMR covers it (but the original symptom still needs the dev-app restart to pick up the PR5 main process).
Test plan
npm run dev: submit a Create turn, confirm no toasts andsession.jsonwrittenMade with Cursor