Description
With interactive client authentication enabled, leaving a page open without authorizing DevTools produces an unhandled rejection after approximately 60 seconds:
Error: [devframe] Timeout waiting for rpc to be trusted
In our Nuxt integration, this also triggers Nuxt's development error overlay on an otherwise working application page. The user does not need to open or interact with DevTools for this to happen.
Environment
The final aligned environment used to verify the workaround was:
@devframes/hub-ui: 1.2.2- Nuxt: 4.6.0
@nuxt/devtools: 4.0.0-beta.4- Vite: 8.3.2
- Node.js: 24.15.0
- pnpm: 12.9.1
- macOS; browser page served through a local HTTPS development proxy
Reproduction
The following was reproduced in our existing Nuxt application before dependency alignment (Vite 8.3.0 and a mixed Devframe dependency graph). We separately inspected the pristine published @devframes/hub-ui@1.2.2 bundle and current upstream source and confirmed the same uncaught timeout call remains. An unpatched minimal 1.2.2 runtime reproduction has not yet been tested:
- Start the Nuxt application in development mode with Nuxt DevTools enabled and interactive client authentication retained.
- Open a working application route in a fresh browser session with no previously authorized DevTools token.
- Do not authorize the DevTools client. Leave the page open for more than 60 seconds.
- Observe the error above in the browser and forwarded development logs, and the Nuxt error overlay.
Expected behavior
An application page should remain usable while DevTools authorization is pending. Background message initialization should wait for authorization, or handle timeout as an expected unauthenticated state, without an unhandled rejection.
Source analysis
At upstream commit 56cc92734d4c8cb2c48f34c95053966969a10f97, packages/hub-ui/src/client/state/messages.ts, line 88 initializes the feed with:
context.rpc.ensureTrusted().then(() => refresh())
The refresh() rejection handler at lines 75–77 handles message-fetch failures, but does not handle rejection of the preceding ensureTrusted() promise.
ensureTrusted() in rpc-live.ts, lines 257–278 defaults to 60_000 ms and rejects with the reported error if trust has not been granted. A timeout of zero or less returns the pending trust promise without a deadline.
Verified downstream workaround / possible fix
Our temporary dependency patch changes the background initialization to:
context.rpc.ensureTrusted(0).then(() => refresh())
With this change, our page remained open for 90 seconds without the timeout error or overlay. Authentication remains enabled: refresh() still runs only after the trust promise resolves.
An indefinite background wait appears appropriate here. Alternatively, a handled timeout with subsequent retry on successful authorization could work. Any timeout-handling alternative should still initialize the feed when the user authorizes later than 60 seconds.
A regression test could leave the messages context untrusted beyond the default deadline, assert no unhandled rejection, then authorize and assert that the initial messages fetch runs.
Related work
#386 fixes trust-deadline and authentication-channel cleanup, and intentionally preserves timeout and unlimited-wait behavior. This report concerns the uncaught timeout in the hub UI's background caller, which remains present in the source linked above.
Description
With interactive client authentication enabled, leaving a page open without authorizing DevTools produces an unhandled rejection after approximately 60 seconds:
In our Nuxt integration, this also triggers Nuxt's development error overlay on an otherwise working application page. The user does not need to open or interact with DevTools for this to happen.
Environment
The final aligned environment used to verify the workaround was:
@devframes/hub-ui: 1.2.2@nuxt/devtools: 4.0.0-beta.4Reproduction
The following was reproduced in our existing Nuxt application before dependency alignment (Vite 8.3.0 and a mixed Devframe dependency graph). We separately inspected the pristine published
@devframes/hub-ui@1.2.2bundle and current upstream source and confirmed the same uncaught timeout call remains. An unpatched minimal 1.2.2 runtime reproduction has not yet been tested:Expected behavior
An application page should remain usable while DevTools authorization is pending. Background message initialization should wait for authorization, or handle timeout as an expected unauthenticated state, without an unhandled rejection.
Source analysis
At upstream commit
56cc92734d4c8cb2c48f34c95053966969a10f97,packages/hub-ui/src/client/state/messages.ts, line 88 initializes the feed with:The
refresh()rejection handler at lines 75–77 handles message-fetch failures, but does not handle rejection of the precedingensureTrusted()promise.ensureTrusted()inrpc-live.ts, lines 257–278 defaults to60_000ms and rejects with the reported error if trust has not been granted. A timeout of zero or less returns the pending trust promise without a deadline.Verified downstream workaround / possible fix
Our temporary dependency patch changes the background initialization to:
With this change, our page remained open for 90 seconds without the timeout error or overlay. Authentication remains enabled:
refresh()still runs only after the trust promise resolves.An indefinite background wait appears appropriate here. Alternatively, a handled timeout with subsequent retry on successful authorization could work. Any timeout-handling alternative should still initialize the feed when the user authorizes later than 60 seconds.
A regression test could leave the messages context untrusted beyond the default deadline, assert no unhandled rejection, then authorize and assert that the initial messages fetch runs.
Related work
#386 fixes trust-deadline and authentication-channel cleanup, and intentionally preserves timeout and unlimited-wait behavior. This report concerns the uncaught timeout in the hub UI's background caller, which remains present in the source linked above.