mirror of
https://github.com/stablyai/orca.git
synced 2026-10-02 16:02:15 +00:00
Brennan Benson
ca0a6ec9be
* Stop the OS keyring probe from gating the first window on Linux 1.4.190 added an at-rest secret protection report and called it from the `app.whenReady()` startup path, before the first window is created. `describeProtectionGap()` asks Electron `safeStorage` whether the OS keyring is usable, and on Linux that is a blocking D-Bus round trip to `org.freedesktop.secrets`. A keyring that is present but locked with no unlock prompter never answers, so the call sits until D-Bus times it out and the app shows no window for over a minute. Measured on Ubuntu 24.04 against a Secret Service that accepts the connection and never replies, time to first window: 1.4.188 1.06s (never contacts the keyring) 1.4.190 76.05s 1.4.190 --password-store=basic 1.06s (probe bypassed) Nothing on the startup path consumes the report, so it now waits for the first window's `ready-to-show`, with a timer fallback because that event can fail to fire when the GPU cannot present and headless serve has no window at all. Same build under the same hanging keyring: first window 80.48s -> 5.31s, with the report still delivered. STA-5765 * Pin the deferral the keyring-probe test exists to protect The suite passed with the probe fired on browser-window-created instead of ready-to-show, with setImmediate dropped, and with the fallback stretched to 10 minutes — every one of which reintroduces the STA-5765 stall. Drain the queue before asserting and bracket the fallback so those mutations fail. Also reformats the file to oxfmt. * Report the keyring gap inline in headless serve Deferring the probe to the first window is right for the desktop app, but serve never opens one, so the fallback timer became its only path. That moved the stall to after `printServeReady`: the runtime advertises itself, a relay or mobile client pairs, and only then does the main thread freeze on the keyring — stalling pings and PTY pumps, which a client reads as a dead host. Serve now reports inline, which is the timing it already had, and blocks before anything is advertised rather than under a live client. STA-5765 * test(secrets): pin the once-guard against a late window reveal The fallback can report first and the window reveal arrive after it; without the guard that probes the keyring a second time, blocking the main thread just as the user starts interacting. No existing case covered that order — removing the guard left all six tests green. * fix(secrets): keep the deferred protection report non-fatal, and pin the wiring Deferring the report moved it off `whenReady`'s promise chain. A throw there was an unhandled rejection the app survives; inside `setImmediate` it is an uncaught exception, and `installUncaughtPipeErrorGuard` re-throws those fatally — so a diagnostic the module documents as deliberately not fatal could kill the app. Wrap the deferred call so it degrades to a warn. Serve keeps the inline posture. Nothing outside index.ts referenced the scheduler, so reverting the call site, or flipping `deferUntilFirstWindow`, left the whole suite green — including the headless-serve regression an earlier review already caught once. Pin the wiring as source text, following the host-port-bootstrap-wiring idiom with every anchor bounded, and pin the two module gates that were only jointly covered. * test(secrets): make the deferral wiring pin resist an inert call site Round 2 of the review gamed the pin it had just added. Both anchors were bounded against -1 but not against overshoot, and the marker matched anywhere in the file — so nesting the call in a block, prefixing it with a guard, or commenting it out all left three green tests standing over a call that never runs. Bound the slice length, and anchor the marker to a statement at whenReady's own indent. Commenting the call out, wrapping it in `if (...) schedule(...)` with or without a block, and flipping the flag each redden now; previously only the unused-import typecheck error caught the first.