fix(api): stop emitting duplicate RUN_ERROR events on streaming failures

[pullfrog]

Summary

Fixes #2666

When a streaming run fails, the client receives two RUN_ERROR SSE events instead of one. This PR eliminates the duplicate.

Root cause

executeRun() in v1.service.ts catches errors during streaming and:

1. Emits a RUN_ERROR SSE event to the client
2. Persists error state to the database
3. Re-throws the error ← the problem

The controller's catch block then catches the re-thrown error and emits a second RUN_ERROR SSE event. This matches the reporter's observation:

data: {"type":"RUN_ERROR","message":"An internal error occurred","code":"INTERNAL_ERROR",...}
data: {"type":"RUN_ERROR","message":"An internal error occurred","code":"INTERNAL_ERROR",...}

Changes

apps/api/src/v1/v1.service.ts

• Remove the re-throw from executeRun()'s catch block. The service now fully handles errors (emit SSE event + persist to DB) without bubbling to the controller.
• Wrap DB cleanup in its own try/catch so a database failure during error cleanup can't propagate and trigger yet another error path. If the DB write fails, it's logged and reported to Sentry, but the RUN_ERROR event has already been sent to the client.

packages/backend/src/services/llm/ai-sdk-client.ts

• Replace silent OpenAI fallback for unknown providers with explicit errors. bedrock and openrouter are defined in the Provider type but had no factory — they silently fell back to OpenAI, causing confusing LLM failures. Now they throw a clear "not yet supported" error.
• Add exhaustive switch check so future Provider additions cause a compile-time error if not handled.

apps/api/src/v1/__tests__/v1.service.test.ts

• Update two tests that expected executeRun to reject — it now resolves after handling errors internally.

Note on the underlying INTERNAL_ERROR

The duplicate RUN_ERROR is a confirmed code bug fixed in this PR. However, the underlying INTERNAL_ERROR that triggers it is a production environment issue (likely related to provider key configuration, model availability, or external API failures). The generic "An internal error occurred" message is intentionally opaque to avoid leaking internal details to clients — the full error is persisted to the database and Sentry for debugging by the Tambo team.

  ^{｜ View workflow run ｜ Triggered by Pullfrog ｜ pullfrog.com ｜ 𝕏}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cloud	Ready	Preview, Comment	Mar 22, 2026 9:53am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
showcase	Skipped		Mar 22, 2026 9:53am
tambo-docs	Skipped		Mar 22, 2026 9:53am