mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
Saxon FletcherandClaude Opus 5.5
5e59b6047e
## Problem
- Assistant responses were capped at 120 seconds and 10 steps, which is
too short for longer reasoning or multi-step tool work.
- When the hosting platform ended a request at that limit, the
connection just dropped. The user got no explanation, and "Thinking…"
and tool rows kept spinning.
- Studio's own tools ignored the request's abort signal, so a stop,
disconnect or deadline couldn't cancel their in-flight requests.
- Aborted responses never closed their Braintrust span. Under TanStack
Start, the remote MCP client was only released on `res.on('close')`,
which the adapter never emits.
## Solution
Uses AI SDK options instead of custom stream handling:
- `maxDuration` goes to 300s and the step limit to 20. `streamText({
timeout: { totalMs } })` stops the response at 270s, leaving time to
finish the stream before the platform cutoff.
- `toUIMessageStream({ messageMetadata })` marks an aborted response
`timedOut: true`. `Chat` ignores `abort` chunks, so the client reads
this flag instead and shows a timeout alert with Retry. The flag is
saved with the message, so the alert survives a reload.
- `toUIMessageStream({ onEnd })` aborts the request whenever the stream
ends, releasing the MCP client on both runtimes. `streamText({ onAbort
})` ends the Braintrust span.
- Studio tools pass the SDK's `abortSignal` to their fetches. MCP tools
already did.
- Reasoning and server-tool rows that never finished show "Response
interrupted" instead of a spinner or "Ran X ✓".
There's no per-tool timeout. Approved SQL and migrations can
legitimately run longer, and aborting the HTTP request doesn't stop the
query in Postgres.
## Review instructions
1. Run the unit tests: `cd apps/studio && pnpm vitest run
lib/api/generate-v4.test.ts lib/ai components/ui/AIAssistantPanel`
2. To see a timeout without waiting 4.5 minutes, temporarily set
`ASSISTANT_TIMEOUT_MS` in `apps/studio/lib/ai/assistant-timeout.ts` to
`15_000` and run `pnpm dev:studio`.
3. Ask the Assistant something that needs several tool calls or long
reasoning, for example "Audit my schema for missing indexes and RLS
gaps, then write the fixes."
4. After 15 seconds, check that:
- the response stops and a "Assistant response timed out" alert appears
with Retry
- any in-progress reasoning or tool row shows "Response interrupted"
instead of spinning
- Retry starts a new response
- reloading the page still shows the alert on that chat
5. Stop a response with the Stop button before the deadline. It should
stop without the timeout alert.
6. With the default 270s, confirm that a normal response completes as
before.
## Checklist
Check all before review:
- [ ] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [ ] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which references
[WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md)
and the docs
[CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md)
guide
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* AI assistant responses can now run for up to five minutes, supporting
longer requests.
* When a response times out, the assistant displays a message suggesting
you retry or ask for a smaller change.
* Incomplete responses now show a “Response interrupted” notice, and
loading indicators stop when generation ends.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
40 lines
1.6 KiB
TypeScript
40 lines
1.6 KiB
TypeScript
import type { UIMessage } from 'ai'
|
|
import z from 'zod'
|
|
|
|
export const assistantMessageMetadataSchema = z
|
|
.object({
|
|
/**
|
|
* Whether any query attached to this message is a logs (ClickHouse) query. A boolean
|
|
* rather than a single source, because one message can attach several queries and
|
|
* only some of them may target the logs backend — the per-attachment dialect is
|
|
* carried by each snippet's own fence in the message text.
|
|
*/
|
|
containsLogsSnippets: z.boolean().optional(),
|
|
/** Set by the server when this response was cut off at the Assistant's deadline. */
|
|
timedOut: z.boolean().optional(),
|
|
})
|
|
.optional()
|
|
|
|
export type AssistantMessageMetadata = z.infer<typeof assistantMessageMetadataSchema>
|
|
|
|
/** Whether the server stopped this assistant response at the Assistant's deadline. */
|
|
export function isTimedOutMessage(message: UIMessage | undefined): boolean {
|
|
if (message?.role !== 'assistant') return false
|
|
const metadata = assistantMessageMetadataSchema.safeParse(message.metadata)
|
|
return metadata.success && metadata.data?.timedOut === true
|
|
}
|
|
|
|
/**
|
|
* Whether any user message in the conversation attached a logs query.
|
|
*
|
|
* Parsed rather than cast — `UIMessage['metadata']` is `unknown`, and metadata can come
|
|
* from a chat persisted by an older build.
|
|
*/
|
|
export function messagesIncludeLogsSnippets(messages: UIMessage[]): boolean {
|
|
return messages.some((message) => {
|
|
if (message.role !== 'user') return false
|
|
const metadata = assistantMessageMetadataSchema.safeParse(message.metadata)
|
|
return metadata.success && metadata.data?.containsLogsSnippets === true
|
|
})
|
|
}
|