Conversation
merge dev into preview for the v2.33.0-preview.20260825 release (api-usage oracle fix)
…w-2340 [WRONG BRANCH] release: promote dev to preview for v2.34.0-preview.20260827
# Conflicts: # package.json
…w-2350 [WRONG BRANCH] promote dev onto preview for v2.35.0-preview
…w-23600829 [WRONG BRANCH] release: v2.36.0-preview.20260829
`preview` carries its own release-bump commits (`release: v2.36.0-preview.20260829`), which are not on `dev`, so the promotion cannot fast-forward: `package.json` is the only conflicting path. Resolved to the version this train publishes, `2.36.0-preview.20260830`, which moves the `preview` channel forward from the 20260829 tip. Every other path takes `dev` (`bb6a6fbdf`) unchanged.
…w-23600830 [WRONG BRANCH] promote dev onto preview for v2.36.0-preview.20260830
# Conflicts: # package.json
…ks up the ReDoS fix)
…w-23800831 [WRONG BRANCH] promote dev onto preview for v2.38.0-preview.20260831
…23900901 # Conflicts: # package.json
[WRONG BRANCH] promote dev onto preview for v2.39.0-preview.20260901
…w-24000902 release: promote dev to preview for v2.40.0-preview.20260902
…rkflow call (lidge-jun#3262) Both v2.40.0 release dispatches (33615174183 preview, 33615177849 main) died at startup_failure: a workflow_call cannot grant its callee more than the calling job holds, and dev-version-bump.yml's job declares contents+pull- requests write. lidge-jun#3129 wired the call but never dispatched a release, so this is its first live run. The caller job now declares exactly the callee's two permissions; no other job in release.yml gains anything. Co-authored-by: jun <jun@lidge.dev> (cherry picked from commit 7ce0ba5)
…w-relfix release: carry the release.yml permissions fix onto preview for v2.40.0-preview.20260902
Brings the reviewed dev head (81a1fc1) onto preview. The only conflict is package.json's version, resolved to the preview channel's next version rather than to either side: preview carried 2.40.0-preview.20260902 and dev carries 2.41.0, and neither is what this publish is. The 37-commit delta since v2.40.0 is reviewed per-commit in devlog/_plan/260903_muse_release_train/011_review_ledger.md.
…w-2410-v2 [WRONG BRANCH] release: v2.41.0-preview.20260903
…w-2410-v3 [WRONG BRANCH] release: refresh preview onto the audit-clean dev head for v2.41.0-preview.20260903
v2.41.0 published from main while this promotion was in flight, so the preview line has to move past it: a 2.41.0-preview version is now BEHIND a released one, which tests/release-version-line.test.ts refuses and npm would refuse after it. dev moved to 2.42.0 in lidge-jun#3354, the automatic post-release bump. Preview follows the same line at 2.42.0-preview.20260903, which is the conflict resolution here: neither side's value, because neither is what this publish is. Also brings the three CI timing-flake fixes from lidge-jun#3351, which is what preview CI failed on twice at 491ffcf. Preflight: 2.42.0-preview.20260903 unpublished on npm, no v2.42.0* tag, no GitHub release, and it moves preview forward from 2.40.0-preview.20260902.
…w-2410-v4 [WRONG BRANCH] release: v2.42.0-preview.20260903
…w-2420-badges [WRONG BRANCH] release: promote dev onto preview for the main-account badge fix
…view preview had diverged from main: it carried 28 merge commits main did not have, while main carried 23 preview did not, so preview could not fast-forward. The divergence was history only - the sole CONTENT difference between the two branches was the package.json version line. This merge takes main (48f8186, the v2.42.0 release commit) into preview and resolves the tree to main's content, so preview now matches the released tree exactly apart from its own prerelease version line. The version could not stay at 2.42.0-preview.20260903: v2.42.0 has published, and compareReleaseTags ranks that prerelease BEHIND its own stable release (-1), which is what tests/release-version-line.test.ts fails on. preview opens the next prerelease line at 2.43.0-preview.20260904, matching dev's 2.43.0.
…w-2430 [WRONG BRANCH] chore(release): promote main v2.42.0 onto preview and open 2.43.0-preview
…review-20260914 [WRONG BRANCH] release: promote verified 2.54.0-preview.20260914 product tree to preview
Promotes the dev product snapshot 62f0222 to the preview train. The 2.55.0 line carries the lidge-jun#4546 cost-guard work: one send budget per logical request with a shared final-recovery reserve, zero-is-zero refusals with a typed error rather than a synthetic 502, compact and the Kiro inner retries admitted against that budget, a finite send ceiling per root workflow with an interactive reserve a fan-out cannot take, and a healthy detour promoted on transient-hold expiry instead of released cold. The previous preview tip 2.54.0-preview.20260914 is already tagged and published and is outranked by v2.54.0, so it could not be re-released; this is a new candidate rather than a re-cut.
…-2550 [WRONG BRANCH] chore(release): promote 2.55.0-preview.20260914 to preview
Same product tree as preview 7bdd1b2 / 2.55.0-preview.20260914, which published successfully with its registry smoke green. Only package.json version differs.
chore(release): promote the verified 2.55.0 product tree to main
…60-v2 [WRONG BRANCH] release: promote the verified 2.56.0 product tree to main
[WRONG BRANCH] chore(release): promote 2.57.0 to main
[WRONG BRANCH] release: promote dev to main for 2.58.0
release: promote 2.59.0 to main
release: promote the verified 2.60.0 tree to main
reasoning_effort caller spellings outside the Codex ladder ("minimal",
"ultra") leaked verbatim to strict upstream enum validators whenever no
pin/cap rewrite fired (chat-native) or the provider had no configured
ladder (openai-responses passthrough) — observed as upstream 400
"Invalid option" on a DeepSeek-fronted gateway.
- chat-native: normalizeForWire now true whenever reasoning_effort is
present (not only after pin/cap), with passthrough kept for "none"
(caller thinking-disable instruction), "enabled"/"disabled"/
"adaptive" (thinkingToggleModels wire values), and compaction turns
(maintenance exemption, same as pin/cap).
- openai-responses/reasoning: the configuredReasoningEfforts===undefined
branch now runs mapReasoningEffort instead of returning early, folding
minimal->low / ultra->max and dropping unresolvable ranks.
- tests: three assertions in model-pinned-effort.test.ts recorded the
buggy passthrough; updated to the mapped wire values with comments.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueNo actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: lidge-jun/opencodex/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughChangesReasoning effort normalization
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Sequence Diagram(s)sequenceDiagram
participant NativeChat
participant normalizePinnedChatEffort
participant mapRoutedResponsesReasoningEffort
participant Provider
NativeChat->>normalizePinnedChatEffort: caller reasoning_effort
normalizePinnedChatEffort->>mapRoutedResponsesReasoningEffort: eligible effort
mapRoutedResponsesReasoningEffort->>Provider: normalized wire value
Merge Risk: ⚪ Minimal · up to The change normalizes eligible reasoning-effort values while preserving documented exceptions, with updated expectations for the resulting provider values. It is ready to merge. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🧪 Generate unit tests (beta)
🛠️ Fix failing CI checks 💡
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. Comment |
|
✅ Deterministic PR hygiene checks passed. |
⏳ DRAFT
What to do
Review readiness checklist
0/4 boxes ticked. Current head: Hygiene✅ Deterministic PR hygiene checks passed. |
리뷰 · 우선순위 58 / 80이 PR은 생각 깊이(effort) 값을 위쪽 서버로 보내기 전에 항상 정리하게 고칩니다. 예전에는 핀(고정값)이나 상한(cap)이 바뀌었을 때만, 또는 제공자에 사다리(허용 목록)가 있을 때만 라인 - base 메인테이너의 판단이 필요한 지점 모르는 effort를 조용히 지울지, 아니면 일부 제공자에서는 400을 그대로 둘지. 그리고 예외 목록을 공유 상수로 뺄지, 이번엔 그대로 두고 나중에 할지. base를 너의 추천 버그 원인과 고침 방향은 맞습니다. 테스트도 예전 “그대로 통과” 기대를 새 매핑에 맞게 고쳤습니다. 이 댓글은 grok-bot이 작성했습니다 |
|
Reviewed for the 260923 bundle round (lane F2, #5674) and not carried. On current |
|
Maintainer triage: Criteria (P2): Medium: provider/client-specific bug with a workaround, bounded enhancement tied to a tracked issue, perf, or CI reliability. Rebased onto current Related issues:
Related / overlapping PRs:
|
Summary
Two call sites gate the wire-level effort sanitizer (
mapReasoningEffort) on whether a rewrite was triggered (pin/cap) or a ladder was configured. On routes with neither, caller-supplied effort spellings outside the Codex ladder pass through verbatim and hit strict upstream enum validators — observed as400 Invalid option: expected one of "low"|"medium"|"high"|"xhigh"|"max"on a DeepSeek-fronted gateway channel.Root cause — two places, same mistake
1.
src/server/chat-native.ts(normalizePinnedChatEffort, native/v1/chat/completions)normalizeForWireonly becomes true when a pin or cap rewrote the value. With neither configured,chatBody.reasoning_effortis forwarded with the caller's spelling.2.
src/adapters/openai-responses/reasoning.ts(mapRoutedResponsesReasoningEffort, Responses pipeline)configuredReasoningEfforts(provider, modelId) === undefinedreturns early, forwardingreasoning.effortverbatim for providers with no configured ladder (e.g. a customopenai-responsesprovider proxying a gateway).Why this is a bug, not a config gap
mapReasoningEffortalready implements the correct semantics for the unconfigured case: identity for valid ladder spellings,minimal→low,ultra→max(the upstream codex-rs boundary), and drop for unknown values. The gates skip this sanitizer precisely where it is needed — custom providers whose upstream validators are stricter than the client vocabulary (Claude Code'soutput_config.effortlegitimately emits a 7-value domain incl.minimal/ultra).Fix
Run the wire mapper whenever an effort value is present, independent of pin/cap/ladder — with three passthrough exemptions confirmed by the existing test suite:
"none"— a caller thinking-disable instruction adapters translate tothinking:{type:"disabled"}(absent ≠ disabled);"enabled"/"disabled"/"adaptive"— provider-wire values consumed bythinkingToggleModelsadapters (openai-chat.ts);Test changes
Three assertions in
tests/codex-integration/model-pinned-effort.test.tsrecorded the buggy passthrough ("preserves unqualified caller spelling"). Updated to assert the mapped wire values (ultra→enabledvia the configuredmax→enabledwireMap alias,ultra→max,low→disabledvia thelow→disabledalias), each with a comment noting the old expectation.Verification
bun x tsc --noEmitcleantests/codex-integration/model-pinned-effort.test.ts: 47 pass / 0 failminimal/ultra400→200,high/xhigh/none200, unknown spelling 400→200 (field dropped → upstream default)🤖 Generated with Claude Code
Summary by CodeRabbit
none,enabled,disabled, andadaptiveare preserved where supported.Review readiness checklist
This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:
All CI tests are green on my local testing.
I pushed my PR to the latest dev commit.
I resolved all correct Codex and CodeRabbit findings.
My PR is ready for review.