Debug and update deliberately

Start diagnosis in the process that owns the failing code. Renderer and preload messages appear in Chromium DevTools. Main-process failures appear in the terminal that ran npm start.

Open renderer tools during development only:

if (!app.isPackaged) {
  win.webContents.openDevTools({ mode: 'detach' })
}

When an IPC request fails, check both places. The renderer may show a rejected promise while the main process contains the original error.

Use this sequence:

1. Reproduce one action from a clean launch.
2. Inspect the renderer rejection and Network or Console details.
3. Find the matching main-process handler and diagnostic.
4. Verify the sender check, input validator, filesystem path, and returned value.
5. Repeat in the packaged app, where paths and bundles differ.

Observe process failures explicitly during development:

win.on('unresponsive', () => {
  console.error('Main window became unresponsive')
})

app.on('render-process-gone', (_event, contents, details) => {
  console.error('Renderer exited', contents.id, details.reason)
})

Do not dump note bodies or credentials while debugging. Log safe IDs, operation names, and error categories.

Keep Electron on a supported release. Electron includes Chromium and Node.js, so framework updates also deliver security fixes from those projects.

Upgrade one Electron major version at a time. Read the matching versioned documentation and breaking changes. Run Node tests, renderer/IPC checks, packaged-app checks, and the security checklist before changing other dependencies.

Record process.versions.electron, process.versions.chrome, and process.versions.node from the main process after each upgrade. This proves which runtime the packaged application actually uses.