Repository navigation
chore: update ref to docs (🤖) - #1231
electron-pr-approver[bot] merged 1 commit into
Conversation
Deploying electron-website with
|
| Latest commit: |
ccb517f
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2fe40270.electron-website.pages.dev |
| Branch Preview URL: | https://docs-update-to-435b189742416.electron-website.pages.dev |
![electron-pr-approver[bot]](https://avatars.githubusercontent.com/u/13409222?s=60&v=4){kind=small}
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.
Beyond the two inline findings, I also checked whether the missing API History blocks flagged by docs/latest/CLAUDE.md are a real gap here: this PR is an automated mirror of upstream electron/electron docs at a bumped commit (docs/latest/.sha), so history-block authorship belongs to the upstream source PRs, not this sync; and the claim that process.crashReporter.start() documentation was wrongly removed doesn't hold up, since breaking-changes.md confirms it was deprecated/removed upstream.
Extended reasoning...
Content-only documentation sync (no code/build changes) touching README nav, several API docs, and a new crash-reporting tutorial; no security-sensitive surface. Two confirmed content bugs (missing sidebar entry for the new tutorial, and a counter-decrement bug in sample code) are already posted as inline findings, so a human look is warranted regardless of my body. I additionally verified two of the three ruled-out History-block/removed-API concerns from the CLAUDE.md guidance and found them not applicable to this auto-synced mirror PR.
| @@ -0,0 +1,380 @@ | |||
| --- | |||
There was a problem hiding this comment.
🟡 (optional) The new Crash Reporting tutorial page won't appear in the docs site's left-hand navigation: it's linked from docs/latest/README.md:68 but sidebars.js was never updated to include it (e.g. under the 'Testing And Debugging' category alongside automated-testing, repl, devtools-extension). Docusaurus's sidebarPath is sidebars.js (docusaurus.config.ts:292), and tutorial docs aren't covered by an autogenerated sidebar entry, so this page has no sidebar item at all, unlike every sibling tutorial page. scripts/check-sidebars.ts, run by npm run lint:sidebars, only checks docs/latest/api (API_DIR='latest/api'), not tutorial docs, so this passes CI silently. … [also at: docs/latest/README.md:68 - New tutorial/crash-reporting.md is linked from docs/latest/README.md's in-page list but not added to sidebars.js, so it won't appear in the site's left nav (no sidebar, no prev/next) after merging. sidebars.js is the actual navigation source (see 'latest/api/crash-reporter' at sidebars.js:266/309),…]
Why this was flagged
…Fix: add 'latest/tutorial/crash-reporting' to sidebars.js's 'Testing And Debugging' category, and extend check-sidebars.ts's coverage to tutorial docs so future additions are caught automatically.
docs/latest/tutorial/crash-reporting.md is a brand-new page added by this diff, reachable only via manual links (crash-reporter.md, app.md, docs/latest/README.md:68). sidebars.js (unchanged by this diff) is the actual navigation source (docusaurus.config.ts:292 sidebarPath) and has no entry for it, nor is docs/latest/tutorial covered by any 'autogenerated' sidebar item (only 'latest/api/structures' is, sidebars.js:377). So the page builds and is linkable but never shows in the site's left nav, unlike every other tutorial page. scripts/check-sidebars.ts's own docstring says this exact class of silent omission is what it exists to prevent, but its API_DIR constant restricts it to 'latest/api',…
Verification: nit. The factual claim holds. The docs sidebar for tutorial pages is a hand-maintained list in sidebars.js (docusaurus.config.ts:292 sidebarPath: require.resolve('./sidebars.js')), and the "Testing And Debugging" category (sidebars.js:169-179) enumerates its items explicitly ('latest/tutorial/automated-testing', ...repl, ...devtools-extension, etc.) with no type: 'autogenerated' entry for…
| let recentCrashes = 0 | ||
|
|
||
| win.webContents.on('render-process-gone', (event, details) => { | ||
| console.error(`Renderer gone: ${details.reason} (exit code ${details.exitCode})`) | ||
| if (details.reason === 'clean-exit') return | ||
|
|
||
| // Reload the page in a new renderer process, but don't retry forever. | ||
| recentCrashes++ | ||
| if (recentCrashes <= 3) { | ||
| win.reload() | ||
| setTimeout(() => { | ||
| recentCrashes-- | ||
| }, 60 * 1000) | ||
| } |
There was a problem hiding this comment.
🟡 (optional) This new tutorial's crash-recovery example can permanently disable itself. recentCrashes++ at crash-reporting.md:234 fires on every renderer crash, but the matching decrement at line 238 only runs when recentCrashes<=3, so each declined crash beyond the 3rd leaves a permanent +1 that is never removed. Over enough crash bursts in the app's life, the counter stays stuck above 3 and win.reload() at line 236 never fires again, contrary to the comment "don't retry forever," which implies temporary backoff, not permanent lockout. Fix: always schedule a matching decrement, or count only crashes within a trailing 60s window.
Why this was flagged
This is new content added by the diff (docs/latest/tutorial/crash-reporting.md is a brand-new file), reached whenever a renderer crashes repeatedly and a developer has copy-pasted the sample from lines 225-244 into a real app. On the 4th+ crash within 60s, recentCrashes++ (line 234) executes but the if (recentCrashes <= 3) guard at line 235 skips the setTimeout that would later decrement it (lines 236-239), so that increment is never undone. Each such 'give-up' event permanently raises the floor of recentCrashes by 1; after enough separate crash bursts over the app's lifetime the counter never returns to <=3, so win.reload() stops being called for any future renderer crash, even unrelated ones weeks later. No other code in the sample resets the counter, and nothing in the surrounding text warns that the guard is one-shot rather than a rolling window.
Verification: nit. The mechanism is real and provable from the code. At docs/latest/tutorial/crash-reporting.md the increment recentCrashes++ (line 234) runs on every non-clean crash, but the compensating decrement is inside the guard: if (recentCrashes <= 3) { win.reload(); setTimeout(() => { recentCrashes-- }, 60 * 1000) } (lines 235-240). So a crash that pushes the counter above 3 increments it but…
Automated PR to update the docs to the latest commit (435b189742416c5a05019b72baf6313b328cdcd6)