You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Desktop (macOS): stacked native "server is temporarily out of service (405)" alerts, each Cancel/OK dismisses only one #14195
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
Run T3 Code Desktop nightly on macOS.
Leave it running normally.
Every so often, several native modal alerts appear at the same time.
No deterministic trigger yet. It happens repeatedly during normal use.
Expected behavior
At most one alert is shown, and dismissing it (Cancel or OK) removes it. A background failure like this should not interrupt with a modal at all.
Actual behavior
3 to 5 identical native macOS alerts stack on top of each other:
The server is temporarily out of service.
Would you like to try again?
(405)
The same alert also shows up with (0) instead of (405).
Cancel and OK each dismiss only the top alert, so I have to click through 3 to 5 dialogs every time it happens.
This text does not appear anywhere in the T3 Code source (apps/, packages/), so the alert is probably not our own dialog.showMessageBox. It looks like a native macOS networking/system alert raised inside the Electron process, maybe from the update path (Squirrel.Mac / electron-updater download) or another background request that triggers repeatedly. Not confirmed.
This dialog is not T3 Code, Squirrel.Mac, or electron-updater. The sentence is the ZK Framework client’s retry confirm, and Electron is presenting it as a native macOS alert because it is running inside this app.
ZK builds it in zAu.confirmRetry as FAILED_TO_RESPONSE, a newline, TRY_AGAIN, then a parenthesized status:
The server is temporarily out of service.
Would you like to try again?
(405)
FAILED_TO_RESPONSE is "The server is temporarily out of service." and TRY_AGAIN is "Would you like to try again?" (msgzk.js). jq.confirm is window.confirm (dom.ts). The number in parentheses is the failed AU request’s HTTP status (au.ts): 405 means that request got Method Not Allowed, and 0 means it failed before an HTTP status (network error, abort, or similar) with an empty status text. OK tells ZK to resend that request, so the same dialog can come straight back.
Nothing in apps/ or packages/ uses this copy. The updater’s own alerts are “You're up to date!”, “Update check failed”, and “Updates unavailable” (apps/desktop/src/window/DesktopApplicationMenu.ts). The desktop asset handler does return an empty 405 for non-GET/HEAD on t3code:// (apps/desktop/src/electron/ElectronProtocol.ts), but that response is never turned into this alert.
The only place this script can run inside the t3code process is the in-app browser. window.confirm from a <webview> is an app-modal native dialog, titled with the app name, with Cancel and OK. will-attach-webview only locks down the guest (apps/desktop/src/window/DesktopWindow.ts); it does not intercept alert / confirm / prompt. Each guest web-contents can have one of these up, and on macOS the alert runs a nested modal loop, so several land on top of each other. Cancel or OK only answers the top one. A background browser tab still runs timers (setBackgroundThrottling(true) slows them, it does not stop them), which matches this showing up during ordinary use with no obvious click.
The 405/0 is that ZK page’s AU call failing, not the T3 server being down. The T3 bug is that a guest page’s confirm() is allowed to stack app-modal dialogs over the whole desktop app.
When it happens again, check the browser panel for every open tab, including ones that are not focused, and reply with the URL (host is enough). If no browser tab is open, this explanation is wrong and we should keep looking.
Activity
juliusmarminge commentedon Sep 29, 2026
Triage
This dialog is not T3 Code, Squirrel.Mac, or electron-updater. The sentence is the ZK Framework client’s retry confirm, and Electron is presenting it as a native macOS alert because it is running inside this app.
ZK builds it in
zAu.confirmRetryasFAILED_TO_RESPONSE, a newline,TRY_AGAIN, then a parenthesized status:FAILED_TO_RESPONSEis"The server is temporarily out of service."andTRY_AGAINis"Would you like to try again?"(msgzk.js).jq.confirmiswindow.confirm(dom.ts). The number in parentheses is the failed AU request’s HTTP status (au.ts):405means that request got Method Not Allowed, and0means it failed before an HTTP status (network error, abort, or similar) with an empty status text. OK tells ZK to resend that request, so the same dialog can come straight back.Nothing in
apps/orpackages/uses this copy. The updater’s own alerts are “You're up to date!”, “Update check failed”, and “Updates unavailable” (apps/desktop/src/window/DesktopApplicationMenu.ts). The desktop asset handler does return an empty405for non-GET/HEAD ont3code://(apps/desktop/src/electron/ElectronProtocol.ts), but that response is never turned into this alert.The only place this script can run inside the
t3codeprocess is the in-app browser.window.confirmfrom a<webview>is an app-modal native dialog, titled with the app name, with Cancel and OK.will-attach-webviewonly locks down the guest (apps/desktop/src/window/DesktopWindow.ts); it does not interceptalert/confirm/prompt. Each guest web-contents can have one of these up, and on macOS the alert runs a nested modal loop, so several land on top of each other. Cancel or OK only answers the top one. A background browser tab still runs timers (setBackgroundThrottling(true)slows them, it does not stop them), which matches this showing up during ordinary use with no obvious click.The 405/0 is that ZK page’s AU call failing, not the T3 server being down. The T3 bug is that a guest page’s
confirm()is allowed to stack app-modal dialogs over the whole desktop app.When it happens again, check the browser panel for every open tab, including ones that are not focused, and reply with the URL (host is enough). If no browser tab is open, this explanation is wrong and we should keep looking.
scriptease commentedon Sep 29, 2026
Thanks my bad, sorry for the inconvenience.