Repository navigation
fix(ai): let slow models use the time research leaves - #69
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing. Comment |
dd312ae to
e4670dd
Compare
This comment has been minimized.
This comment has been minimized.
Claude Opus 5 needs about 68 s to write a case, so every Opus case generation hit the 60 s provider timeout and returned 500. Each call now shares one 140 s request budget, which stays under Supabase's 150 s response limit. Research, the main call, and its JSON repair retry all use what is left. The model matrix reproduces the failure and proves the fix. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The post-generation Jev source-usage check shared the request budget, so a model that finished near the deadline could lose its completed case to a 500. The check now follows only the client's signal and its own 8 s Jev timeout, and the provider budget drops to 130 s to leave room for it under Supabase's 150 s limit. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
01903a9 to
3334dc2
Compare
Why
The model matrix from #68 generates one case with every catalog model. Claude Opus 5 failed every time: research takes about 30 s, and Opus then needs about 65 to 68 s to write the case, but the
aifunction aborted each provider call at a fixed 60 s. Every Opus case generation in production returns 500 today. Two direct OpenRouter calls with the same prompt took 68.3 s and 68.7 s.Claude Sonnet 5, the Pro default, took 55.9 s in the same run, so it fails intermittently under load too.
Change
supabase/functions/ai/index.tsonly. Each request gets one 130 s budget (AbortSignal.anyof the client's signal andAbortSignal.timeout). Research, the main call, and its JSON repair retry all share it. Supabase answers 504 when a function hasn't responded within 150 s on every plan, so 130 s leaves room for the 8 s post-generation source-usage check, logging, and saving. That check follows only the client's signal, so it cannot turn a finished case into a 500. Before this change, the worst case (30 s research + 60 s call + 60 s repair) could already reach 150 s.Timeouts still surface as "The signal has been aborted", which the client already maps to its "Request timed out" message.
Evidence
npm run test:edge: 238 passed.ai generate status: 500after the 60 s abort.Deploy
After merge this needs
supabase functions deploy aito reach production. Vercel doesn't deploy Edge Functions.Not fixed here
DeepSeek V4 Flash is unreliable for case generation independent of the timeout. Today it timed out once, passed once at 53 s, and once returned empty content after 8 s.
Stacked on #68; retarget to
mainafter #68 merges.🤖 Generated with Claude Code
No outstanding findings block merging.
Summary
The PR gives AI generation a shared 130-second work budget so slow models can use time left after research. The completed-case source-usage check no longer inherits that budget.
Reviews (2) · Last reviewed commit: "fix(ai): keep a finished case when the s..."