[amitbardos]

Stacked on #87.

Base44 holds chat/message and chat/submit-tool-call-input open for the whole builder turn. The platform proxy waited for it, up to BUILDER_TIMEOUT_MS (120s), so a long build that was working could still come back as a timeout. useChat's ChatBackend expects both calls to resolve once the request is accepted. This applies Tiny Sunny's waitForRefusal to src/app/api/base44/platform/route.ts.

What changes

• sendMessage and submitToolCallInput are flagged answersOnAccept. The proxy waits 3s (REFUSAL_WINDOW_MS):
  • If Base44 answers inside the window, the browser gets the same response as before. A refusal still goes through UpstreamFailure, keeping today's status and error shape: 403 with detail, 401 → 501 bridge_misconfigured, 502 for a fetch that never completed. A fast success still returns its body.
  • If the window passes first, the browser gets 200 { ok: true }. The browser never read this body anyway; the chat follows the turn over the live session.
• The request to Base44 keeps running after the response, under Next's after(). Dropping that connection cancels the turn ("Processing was interrupted"). A failure after the response is logged as [base44/platform] <action> failed after it was accepted: <status>.
• The allow-list, the ownership gate (404 before any upstream call) and X-Request-ID forwarding are unchanged.
• Comments: removed the reference to Vercel's 300s ceiling. BUILDER_TIMEOUT_MS now says that Netlify ends a synchronous function at 60s, counting after() work, and that the 120s ceiling is for hosts with no such limit. The base44Platform.ts and README troubleshooting rows match.

Netlify caveat

Netlify's synchronous execution limit is 60s and can't be configured. Its waitUntil, which is what after() uses, runs within that limit (config defaults, waitUntil). So in production a builder turn longer than 60s is still cut when the function ends, as it was before this change: the old 120s timeout never applied on Netlify either. Fixing that would take a background function or a change on Base44's side; this PR doesn't attempt either. createApp (whose initial_message build runs inside the call) and deployApp still wait for the whole call, since the browser needs their response.

Testing

• npm run typecheck, eslint on the changed files, npm run base44:smoke: all pass.
• Against a local fake Base44 (dev server with BASE44_PLATFORM_HOST pointed at it), both actions:
  • 403 at 100ms → browser gets 403 {"error":"Upstream 403","detail":…}, same as before
  • 200 at 200ms → browser gets Base44's body, same as before
  • 200 at 6s → browser gets {"ok":true} at ~3.0s; the upstream connection stayed open until Base44 answered (no client drop)
  • 500 at 5s → browser gets {"ok":true} at ~3.0s; the server logs failed after it was accepted: 500
  • X-Request-ID: submit-toolu_1 still reached upstream
• Not tested: a live Base44 build, or a Netlify deploy (after() → waitUntil under the OpenNext adapter).

🤖 Generated with Claude Code