For people using the Studio AI Assistant: have you encountered requests that remain stuck until you refresh or navigate away? I am trying to understand whether this controlled failure/simulation corresponds to anything users have seen in practice.
I have been testing several reliability findings against the actual affected Supabase code instead of relying on static analysis alone.
One result I could reproduce concerns the Studio AI request path.
The queryAi function has a default timeout of zero. Its timeout logic only runs when the supplied timeout is greater than zero.
I tested the real upstream function with a controlled SSE connection that opened but never returned data or an error.
I then applied a minimal control change that introduced a default timeout and closed the stream when that timeout fired. Under the same test, the request terminated and the active connection count returned to zero.
I tested both a scan-era representative Supabase revision and the then-current master. The affected source file was byte-identical between them.
This is not a claim that I observed a specific production incident or completed a full Studio browser E2E test.
Evidence and reproduction code:
The user reports an issue with the Supabase Studio AI Assistant where requests remain pending indefinitely until a refresh or navigation occurs. They identified that the queryAi function's default timeout is zero, causing the timeout logic to not execute unless a positive timeout is set. The user tested a fix by introducing a default timeout, which resolved the issue in their controlled environment.