bug(extensions): runtime-api request intermittently rejected for an unrecognized extensionId key

[Juliusolsson05]

Summary

src/main/extensions/electron.system.test.ts › keeps one managed runtime across commands, view requests, updates and uninstall failed once in a full local vitest run, and it failed on a real ZodError, not a timeout. Run on its own immediately afterwards, the same file passed 2/2. It also passed in an earlier full run on the same branch.

Seen on the #1186 branch after merging origin/main at 2f38d5bb. That branch does not touch src/main/extensions, and the extension-related files it does touch only change a comment or an import.

Evidence

Error occurred in handler for 'extensions:runtime-api': ZodError: [
  { "code": "unrecognized_keys", "keys": ["extensionId"], "path": [],
    "message": "Unrecognized key: \"extensionId\"" } ]
    at onApi (.../agent-code-extension-frames-*/main.cjs:17196:45)
Error occurred in handler for 'extensions:runtime-api': Error: No handler registered for 'extensions:runtime-api'
AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ [ '/' ]
- []
Error: Extension Electron checks failed (1)

The command was node scripts/check-extension-frames.mjs --runtime-only, run from the vitest system project on Node 24.14.1 on macOS.

Expected

The runtime-API request shape either matches the strict schema every time, or never does.

Actual

Under full-suite load, a runtime-API request intermittently carried extensionId, which the strict schema rejects. After that the handler was reported as unregistered, and a later assertion saw an unexpected '/' entry.

This suggests an ordering or lifecycle race between the runtime's API calls and handler registration or teardown. It may only show up when the machine is under load.

Impact

• The system test is intermittent.
• If the same race is possible in the app, an extension's runtime API call could be refused with a schema error.