Preventing infinite 401 retries and reconnecting motherduck/wasm-client with invalid token without page reload

Fabian · 2026-05-29T23:46:56.047Z

When a @motherduck/wasm-client connection is initialized without a token / with an invalid token (as can happen in reactive notebooks), the client will continuously hammer https://api.motherduck.com/sessions.CreateShortLivedTokenService/CreateShortLivedToken and receive 401 responses. How can I stop it from doing that and preferably reinitialize the connection without having to reload the page?

Noah S.
·
(edited)·
Hey Fabian, is this with Observable as mentioned in previous threads, or something you're building?
Fabian
·
·
Yep, Observable (although I'd expect it to repro in other environments)
Fabian
·
(edited)·
Looks like getAsyncDuckDb always returns a singleton promise (which has no setter exposed), so my only chance would be to somehow break the loop (and even then I probably couldn't reinitialize)
Noah S.
·
·
Thanks for raising this! This appears to be a known issue and I've raised your use-case internally. We might have a workaround coming soon -- I will keep you posted. Today, the only workaround is to reload the webpage. Does this unblock you for now?
Fabian
·
·
I can probably make do since I can delay the create() call until a token has been provided. I might also look into loading the worker directly
Fabian
·
(edited)·
... I'm good now. 👍 This loads the extension directly and terminates the worker on auth errors: https://observablehq.com/@mootari/motherduck
🙌1
Fabian
·
(edited)·
... Streaming seems to work as well after I dropped an obsolete monkeypatch for PIVOT. Although duckdb buffers way too many results and then streams the rest rather slowly, which may suggest a watermark issue.
Fabian
·
·
I'm also seeing a few "unassociated response" warnings for MD_EVENT (with "CatalogChangeEvent"), which I assume would have been handled by Motherduck's bundle. All in all this is clearly only a stopgap solution, and I'm eager to see how new releases of the wasm client will fare.
Fabian
·
(edited)·
Just in case it's helpful (if not, no worries), these are the batch timings that I get for 6M rows with the above implementation. It seems that the client buffers the entire result set before passing it on. The narrow timing here also suggests that any streaming issues in Observable's data tables may be caused by the table implementation, not the MD backend. (And fwiw, I'm fully aware that this use case is likely unsupported; I'm mostly documenting things for myself)
Noah S.
·
·
Hey Fabian, thanks for this! I will make sure this gets to our WASM wizards internally 🙏
🙌1
Noah S.
·
·
Glad to see you're unblocked for now.
Fabian
·
·
Noah S. I ran into what might be an edge case:
1.
my trial ended, and I downgraded to Lite
2.
that voided my Read Scaling token
3.
instead of getting an auth error for the token, I got an endless stream of grpc errors (unknown status '7', iirc) which eventually hit the call stack size limit
Noah S.
·
·
Thanks Fabian for bringing this to our attention! I'll forward this to engineering.
Noah S.
·
·
Hey Fabian, you may be interested in a new command available in the latest WASM client: terminateDuckDB() (docs). This lets you terminate the DuckDB instance in the browser so you can swap tokens or reconnect without having to refresh.
Fabian
·
(edited)·
Noah S. Thanks for the update, but as far as I can tell the method has been around since 1.5.2-r.1 (just undocumented) and requires a successful prior connection. An instance that fails to authenticate can still not be cleaned up and will continue to spam CreateShortLivedToken requests that 401.

Preventing infinite 401 retries and reconnecting motherduck/wasm-client with invalid token without page reload

23 comments

Preventing infinite 401 retries and reconnecting motherduck/wasm-client with invalid token without page reload

23 comments