fix(providers/openai): send explicit stream:false in chat completion body by Ptah-CT · Pull Request #526 · rohitg00/agentmemory

Ptah-CT · 2026-05-19T06:52:58Z

Summary

OpenAIProvider.call omits the stream field, relying on the OpenAI spec default of false. Some OpenAI-compatible proxies disagree and return text/event-stream instead of JSON, which crashes response.json() with:

Unexpected token 'd', "data: {"id"... is not valid JSON

After a few of these in a row, ResilientProvider's circuit breaker trips and every subsequent compression / summarisation / reflection fails with circuit_breaker_open — silently disabling all LLM-backed memory enrichment.

This PR sends stream: false explicitly in the request body.

Why this is upstream-worthy even with a proxy-side fix

Reproduced concretely with 9Router, an OpenAI-compatible proxy that ships with default stream resolved as body.stream !== false (i.e. undefined !== false → true). I opened decolua/9router#1272 against that, but defensive stream: false here protects against:

Other OpenAI-compatible endpoints with the same spec gap (older self-hosted proxies, vLLM compat shims, custom routers)
9Router users on versions < 0.4.56 (the fix has not shipped yet)
Future regressions in any proxy that re-introduces the bug

For spec-compliant endpoints (openai.com, Azure OpenAI, well-behaved proxies): no behavior change — they already default to non-streaming when stream is absent, so setting it is a no-op.

Repro

EMBEDDING_PROVIDER=openrouter
OPENAI_API_KEY=...
OPENAI_BASE_URL=http://localhost:20128/v1   # any proxy that streams by default
OPENAI_MODEL=haiku                          # any model that proxy understands

Then:

curl -X POST http://localhost:3111/agentmemory/remember \
  -H 'content-type: application/json' \
  -d '{"content":"test","type":"fact","concepts":["test"]}'

Wrapper log without this PR:

[agentmemory] error Compression failed
  {"obsId":"...","error":"Unexpected token 'd', \"data: {\"id\"... is not valid JSON"}
[agentmemory] error Compression failed
  {"obsId":"...","error":"circuit_breaker_open"}  # ← all subsequent calls

With this PR: response is JSON, data.choices[0].message.content extracted, compress succeeds.

Test plan

Existing tests pass
Manual: against a known-good endpoint (openai.com, Azure) — request body now contains "stream":false, response shape unchanged
Manual: against an SSE-default proxy (9Router) — request now resolves correctly instead of SSE-crashing the JSON parser

Summary by CodeRabbit

Bug Fixes
- Fixed compatibility issues with OpenAI-compatible proxy services that were causing API request failures. This ensures that chat completion requests work reliably whether you're using official OpenAI services or compatible alternative providers. Users will no longer experience unexpected response format errors during API operations.

…body OpenAI API spec defines `stream` as defaulting to false when absent, so the current code (which omits it) should yield JSON. Some OpenAI-compatible proxies disagree and default to text/event-stream, which crashes the `response.json()` parser below with: Unexpected token 'd', "data: {"id"... is not valid JSON After a few of these in a row, the resilient wrapper's circuit breaker trips and all subsequent compression calls fail with `circuit_breaker_open`, silently disabling LLM-backed compression / summarisation / reflection. Reproduced upstream in decolua/9router#1260: 9Router's `handleChatCore` returns SSE unless `stream: false` is explicit. PR decolua/9router#1272 fixes the proxy side, but sending the field explicitly here is defensive — other OpenAI-compatible endpoints (older self-hosted proxies, vLLM compat shims, …) hit the same spec gap. No behavior change for spec-compliant endpoints (openai.com, Azure OpenAI, well-behaved proxies): they already default to non-streaming when `stream` is absent, so making it explicit is a no-op there. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

vercel · 2026-05-19T06:53:02Z

@Ptah-CT is attempting to deploy a commit to the rohitg00's projects Team on Vercel.

A member of the Team first needs to authorize it.

coderabbitai · 2026-05-19T06:53:10Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0d6d873a-6853-4f81-a0bd-6de731fd3593

📥 Commits

Reviewing files that changed from the base of the PR and between 68fddd4 and 1b50a72.

📒 Files selected for processing (1)

src/providers/openai.ts

📝 Walkthrough

Walkthrough

The OpenAIProvider now explicitly includes stream: false in the chat completions request body. This prevents OpenAI-compatible proxies that default to streaming when the field is omitted from returning text/event-stream responses, which previously broke JSON response parsing.

Changes

OpenAI Provider Streaming Fix

Layer / File(s)	Summary
Explicit stream field for compatibility `src/providers/openai.ts`	Chat completions request body now includes `stream: false` to prevent OpenAI-compatible proxies from defaulting to streaming format and breaking response.json() calls.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Possibly related PRs

rohitg00/agentmemory#307: Both PRs modify src/providers/openai.ts's OpenAI-compatible chat-completions request construction, with this PR adding explicit stream: false while that PR introduces the initial fetch-based /v1/chat/completions implementation.

Poem

🐰 A stream runs swift through proxy lands,
But now we say "no, stop right there!"
With false in hand and firm commands,
We parse the JSON clean and fair.
No more the text-event-stream dance,
Just structured data—the rabbit's chance! 🌟

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding explicit stream:false to the OpenAI chat completion request body, which is the core fix addressed in this PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint skipped: no ESLint configuration detected in root package.json. To enable, add eslint to devDependencies.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

rohitg00 · 2026-05-20T15:34:05Z

Thanks @Ptah-CT — circuit-breaker silently disabling LLM compression is a nasty failure mode; appreciate the load-bearing comment so future readers see the why. Merged.

…uard (#588) Three concerns surfaced when auditing PRs merged since v0.9.21: 1) Graph parser regex from #494 was correct for self-closing tags ONLY when they're the only entity in the document. With a self-closing entity followed by an explicit-close entity, the greedy `[^>]*` ate the trailing `/` of the self-close, the alternation fell through to the explicit-close branch, and `[\s\S]*?` ran ahead to the *next* `</entity>` — merging two entity declarations into one match and silently dropping a node. Switch to lazy `[^>]*?` so the self-closing alternation gets first chance. Test from #494 (which was failing on main but I didn't notice) now passes. 2) #386 shipped `${AGENTMEMORY_URL}` / `${AGENTMEMORY_SECRET}` placeholders in plugin/.mcp.json. Claude Code and Cursor expand those at MCP launch time; some hosts pass the literal string through. A truthy literal `"${AGENTMEMORY_URL}"` defeats the existing `|| DEFAULT_URL` fallback and would have the shim POST to `${AGENTMEMORY_URL}/agentmemory/...` (DNS failure). Add a defensive guard in src/mcp/rest-proxy.ts that strips any value of the form `${...}` so the fallback engages. Mirror in src/mcp/standalone.ts's mode-announce log line. 3) CHANGELOG entries for all PRs landed since v0.9.21 (#321, #325, #386, #454, #494, #526, #542, #560, #561, #562, #564, #567) plus the regex + env-guard hardening here. Validation: - npm test → 98 files, 1091 tests pass - npm pack → 142 files, fresh install clean, iii-sdk@0.11.2 pinned, plugin/ shipped with hooks/scripts/skills/opencode/ - New test file covers 8 placeholder cases (unset, empty, `${VAR}` literal, mismatched braces, real values with $, unclosed `${`, no-braces `$VAR`).

Ptah-CT mentioned this pull request May 19, 2026

fix: streaming default in handleChatCore treats absent stream param as streaming decolua/9router#1260

Open

openoms mentioned this pull request May 19, 2026

Support OpenAI/Codex subscription-auth fallback without requiring OPENAI_API_KEY #527

Open

rohitg00 merged commit a994514 into rohitg00:main May 20, 2026
1 of 2 checks passed

coderabbitai Bot mentioned this pull request May 20, 2026

feat(provider): AGENTMEMORY_DISABLE_THINKING to recover structured output on Qwen3/GLM/Kimi #569

Open

3 tasks

rohitg00 mentioned this pull request May 21, 2026

fix: pre-release hardening for 0.9.22 — regex correctness + MCP env guard #588

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(providers/openai): send explicit stream:false in chat completion body#526

fix(providers/openai): send explicit stream:false in chat completion body#526
rohitg00 merged 1 commit into
rohitg00:mainfrom
Ptah-CT:fix/openai-provider-explicit-stream-false

Ptah-CT commented May 19, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

vercel Bot commented May 19, 2026

Uh oh!

coderabbitai Bot commented May 19, 2026 •

edited

Loading

Walkthrough

Changes

Estimated code review effort

Possibly related PRs

Poem

Uh oh!

Uh oh!

rohitg00 commented May 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Ptah-CT commented May 19, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why this is upstream-worthy even with a proxy-side fix

Repro

Test plan

Related

Summary by CodeRabbit

Uh oh!

vercel Bot commented May 19, 2026

Uh oh!

coderabbitai Bot commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Possibly related PRs

Poem

Uh oh!

Uh oh!

rohitg00 commented May 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Ptah-CT commented May 19, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented May 19, 2026 •

edited

Loading