Files
OmniRoute/changelog.d
tom c193595db6 fix(open-sse): promote reasoning_details text to reasoning_content even when reasoning present (#12665) (#12688)
* fix(open-sse): promote reasoning_details text to reasoning_content even when reasoning present (#12665)

OpenRouter thinking models return both a "reasoning" string and a
"reasoning_details[].text" array for the same thinking trace. OmniRoute's
reasoning promotion gated on "is any readable value present" (which includes
the "reasoning" alias), so reasoning_content was never populated and clients
like opencode that only read reasoning_content lost all thinking traces.
Encrypted-only reasoning_details items are left intact (not flattened).

Fixes all three promotion gates:
- non-streaming: copyOpenAICompatibleReasoningFields now mirrors
  reasoning_details[].text into reasoning_content unless reasoning_content
  itself is present
- streaming mirror block: same gate fix on getReadableReasoningValue
- streaming passthrough: force re-serialization when sanitize added a
  reasoning_content the upstream delta did not carry (needsReserialization
  was false because hasUnsupportedReasoningSignal requires !readable)

Tests: non-streaming + streaming unit regressions and an integration E2E
that drives the full handleChat path against a mock OpenRouter provider.

Also closes the same latent gate in the JSON-to-SSE rehydrator
(jsonToSse.ts buildReasoningDelta): a populated reasoning string used to
short-circuit the unsupported-alias mirror, so reasoning_details[].text
was dropped when synthesizing an SSE stream from a non-streaming JSON
body. Adds a #12665 regression test for that path, fixes an over-indented
brace in stream.ts (lint), and restores the missing trailing newline in
the E2E.

* docs(changelog): add fragment for #12688 — fix(open-sse): promote reasoning_details text to reasoning_content even when reasoning present

* fix(tests): replace any with typed casts in #12665 regressions to satisfy no-explicit-any gate
2026-09-19 00:02:22 -03:00
..
2026-07-13 09:12:40 -03:00

changelog.d/ — changelog fragments

A PR never edits CHANGELOG.md directly during the cycle. Instead it adds ONE new file here — its changelog entry as a fragment. Two PRs never touch the same file, so changelog merge conflicts (the "CHANGELOG-eat" cascade that forced a re-sync push + full CI re-run after every sibling merge) are structurally impossible.

Convention

Directory Aggregates under
features/ ### ✨ New Features
fixes/ ### 🐛 Bug Fixes
maintenance/ ### 📝 Maintenance
  • Filename: <PR-number>-<short-slug>.md (e.g. fixes/6700-dockerfile-better-sqlite3.md). The PR number prefix keeps aggregation order deterministic.
  • Content: the exact bullet line(s) that should land in CHANGELOG.md, starting with - . Multi-line (continuation) bullets are fine. Keep the repo's credit format: (#PR — thanks @user).
  • One fragment per PR (rarely more, e.g. a PR that both fixes and adds).

Example

changelog.d/fixes/6496-cloudflare-relay-worker-syntax.md:

- **fix(providers):** Cloudflare relay Worker deploys use Service Worker syntax with `body_part` metadata ([#6496](https://github.com/diegosouzapw/OmniRoute/pull/6496)) — thanks @SeaXen

Aggregation

The release captain (or /generate-release) folds all fragments into CHANGELOG.md and deletes them:

node scripts/release/aggregate-changelog.mjs            # write + delete fragments
node scripts/release/aggregate-changelog.mjs --dry-run  # preview only

Fragment well-formedness is enforced by npm run check:changelog-integrity (the same gate that guards against CHANGELOG-eat for legacy direct edits).