fix(sse): non-stream OpenAI-compatible requests no longer coerced to SSE when Accept lists application/json (#5305)

[diegosouzapw]

Closes #5305

Problem

The Vercel AI SDK / OpenAI SDK non-stream path (doGenerate() / generateText()) omits stream in the body and sends Accept: application/json, text/event-stream, then parses the response as JSON. OmniRoute coerced these into SSE, so the caller received:

APICallError [AI_APICallError]: Invalid JSON response
JSONParseError: Unexpected token 'd', "data: {"id"... is not valid JSON

Two code paths did the coercion (both confirmed by the reporter's excellent source analysis):

• src/sse/handlers/chat.ts — route-level Accept override (FIX fix(docker): use /api/monitoring/health for Docker healthcheck (#296) #302): forced stream=true whenever Accept contained text/event-stream and the body omitted stream.
• open-sse/utils/aiSdkCompat.ts::resolveStreamFlag — clientWantsJsonResponse returns false for application/json, text/event-stream, so the fallback streamed.

Fix

An Accept header that explicitly lists application/json is treated as a JSON opt-in, even when it also lists text/event-stream. Concretely:

• Only a pure Accept: text/event-stream (no application/json) still opts an omitted-stream request into SSE.
• An explicit body stream value (true/false) always wins (unchanged).
• */* / no Accept → still streams (legacy default unchanged).
• providerRequiresStreaming (stream-only providers, [BUG]: 400 Improperly formed request when sending requests with 24 tools #2081) → still streams (unchanged).

The two former copies of the decision are unified into a shared acceptHeaderForcesStream(acceptHeader, bodyStream) helper used by both chat.ts and (mirrored in) resolveStreamFlag.

TDD / Validation (Hard Rule #18)

New tests/unit/sse-nonstream-accept-5305.test.ts (failed on the unfixed code — the helper didn't exist and resolveStreamFlag(undefined, "application/json, text/event-stream", "openai") returned true; passes after):

• acceptHeaderForcesStream: 5 cases (Vercel signature → no force; pure SSE → force; pure JSON → no force; explicit body wins; no Accept).
• resolveStreamFlag: 5 cases (openai mixed → JSON; openai pure-SSE → stream; openai */*/none → stream; explicit stream:true wins; forceStream provider wins).

Results:

• [BUG] /v1/chat/completions can return SSE for non-stream OpenAI-compatible requests when stream is omitted #5305 suite 10/10; regression 27/27 (t26-ai-sdk-accept-header-compat, resolve-stream-flag, chatcore-json-body-to-sse); stream-executor sweep 81/81 (cli-stream, blackbox-web, perplexity-web, mimocode-executor) — no regression.
• typecheck:core clean, eslint 0 errors, check:file-size clean (chat.ts net -3; new test in a fresh file), check:test-discovery OK.

Note

A per-key workaround already exists (streamDefaultMode: "json"); this makes the default spec-aligned (the body stream field is authoritative; Accept is a transport hint) so SDK clients work out of the box. The change is scoped to OpenAI-format requests — the claude / openai-responses branches of resolveStreamFlag are untouched.

[gemini-code-assist]

Code Review

This pull request resolves an issue where clients using the OpenAI or Vercel AI SDK non-stream signature (omitting stream in the body but sending Accept: application/json, text/event-stream) were incorrectly forced into SSE streaming mode. It introduces the acceptHeaderForcesStream utility and updates resolveStreamFlag and handleChat to ensure these requests default to JSON. A new test file is also added. The review feedback correctly points out that the new test file should use the repository's standard vitest framework instead of the Node.js built-in node:test and node:assert modules.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The repository uses Vitest as its primary testing framework (as indicated by vitest.config.ts in the root and the repository style guide references to Vitest files). Importing from node:test and node:assert introduces inconsistency and can cause issues with Vitest's test runner, coverage tools, or mocking features. Using vitest instead of the Node.js built-in test runner ensures consistency across the test suite.

Suggested change

	import { describe, it } from "node:test";
	import assert from "node:assert/strict";
	import { describe, it, assert } from "vitest";