fix(data-process): fix crash-loop detection and renderer hang on give-up - #10388
Open
jackkav wants to merge 1 commit into
Open
fix(data-process): fix crash-loop detection and renderer hang on give-up#10388jackkav wants to merge 1 commit into
jackkav wants to merge 1 commit into
Conversation
Two bugs in the crash-restart manager's handleExit(): 1. restartCount was reset to 0 after every successful restart (i.e. as soon as the child reached 'ready'), not just when restarts were spaced apart. A process that repeatedly reaches ready and then crashes again seconds later would reset the counter each time, defeating MAX_RESTARTS for a ready-then-crash loop. The existing RESTART_WINDOW_MS check already decays the counter correctly for restarts that occur further apart, so the extra reset is both redundant and harmful — removed it. 2. When MAX_RESTARTS is exceeded, only mainRpc (the main process's own RPC client) was invalidated. Renderer windows hold their own PortRpc instances (attached via attachDataPortRpc in preload), which are only invalidated by the 'data-process.restarting' IPC message. That message was never sent on the give-up path, so pending and future database/service calls from any window would hang forever with no error once the data process is confirmed dead.
✅ Circular References ReportGenerated at: 2026-08-13T07:43:05.892Z Summary
Click to view all circular references in PR (9)Click to view all circular references in base branch (9)Analysis✅ No Change: This PR does not introduce or remove any circular references. This report was generated automatically by comparing against the |
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.
Feedback PR for #10259 — two related bugs in
data-process-manager.ts'shandleExit().1.
restartCountreset underminesMAX_RESTARTSrestartCountwas zeroed as soon as the child reachedready, regardless of how quickly it crashed afterwards. If the utility process crashes shortly after reaching ready every time (e.g. a bug that only manifests once init finishes), each restart attempt resets the counter before the next crash increments it again — sorestartCountnever climbs past 1 andMAX_RESTARTS(10) never trips. The app would restart the data process forever instead of giving up.The existing
RESTART_WINDOW_MScheck in the same function already decays the counter correctly for restarts that are spaced more than 60s apart:Removing the extra reset-on-success lets that time-based logic do its job as intended, while still correctly capping tight ready-then-crash loops.
2. Renderer windows never learn the data process is permanently gone
When
MAX_RESTARTSis exceeded, onlymainRpc(the main process's own RPC client) was invalidated:Each
BrowserWindow's ownPortRpc(attached viaattachDataPortRpcin preload) is only invalidated when it receives the'data-process.restarting'IPC message — which is sent on every retry but not on the final give-up path. So once the data process is confirmed dead, any pending or futuredatabase/servicescall from a window would hang forever with no error, rather than rejecting with a clear message.Fix: broadcast
'data-process.restarting'to all windows on the give-up path too, so their pending/futureinvoke()calls reject instead of hanging.Testing
npx tsc --noEmitandnpx eslintclean on the changed file.serialization.test.tspasses;port-rpc.test.tsin this workspace currently fails locally due to an unrelated brokenelectronpostinstall in my worktree, not this change (confirmed the same file's other test suite runs fine and the failure isElectron failed to install correctly, not a code issue).