Skip to content

merge queue: checking release/v3.8.49 (7123236), #7093, #7098, #7100, #7102 and #7103 together - #7462

Closed
mergify[bot] wants to merge 18 commits into
release/v3.8.49from
mergify/merge-queue/975719d4e3
Closed

mergify[bot] wants to merge 18 commits into
release/v3.8.49from
mergify/merge-queue/975719d4e3

Conversation

@mergify

@mergify mergify Bot commented Jul 16, 2026 •

Copy link
Copy Markdown

✨ Pull request #7093 ahead in the queue was removed (reason: pull request dequeued). The pull request #7103 has been requeued. ✨

Branch release/v3.8.49 (7123236), #7093, #7098, #7100, #7102 and #7103 are queued together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #7103.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule release for merge:

  • #check-pending=0
  • check-success=Merge integrity (changelog + generated skills)
  • #check-success>=1
  • any of:
    • #check-failure=0
    • all of:
      • #check-failure=1
      • check-failure=dast-smoke

Required conditions to stay in the queue:

---
checking_base_sha: 438a96232cfb34ef50561966b57ca92687d339f6
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 7103
    scopes: []
scopes: []
...

diegosouzapw and others added 18 commits July 13, 2026 23:06
…ort from 9router#1321)

The reasoning_content injector already handles DeepSeek/Kimi/K2/MiniMax thinking-mode upstreams, echoing a placeholder reasoning_content on assistant turns that lack one. Its THINKING_MODEL_PATTERNS list omitted the xiaomi-tokenplan mimo family, so requests through xiaomi-tokenplan/mimo-v2.5-pro still hit upstream's 400 'reasoning_content in the thinking mode must be passed back to the API', making the model unusable in multi-turn conversations (e.g. Codex CLI). Add a /\bmimo\b/i pattern so mimo models get the same treatment.

Reported-by: z.wl (@xxue-z) (decolua/9router#1321)
…om 9router#1556)

Codex/OpenAI's Responses API rejects JSON Schema pattern fields using regex lookaround (e.g. ^(?=.*@).+$) with a 400 'regex lookaround is not supported' error. The existing numeric-field sanitizer (coerceSchemaNumericFields) was only wired into the translated-request path (openai-to-claude.ts), not the native codex/openai passthrough path (normalizeCodexTools in open-sse/executors/codex/tools.ts), so lookahead/lookbehind patterns reached upstream unmodified and broke tool calls for clients that emit them (e.g. IDE agent harnesses validating an email field).

Reported-by: evin (@evinjohnn) (decolua/9router#1556)
… (port from 9router#2132)

Root cause: SmartCrusher's system-message guard only excluded role === "system", but Codex CLI (open-sse/executors/codex.ts) sends its instructions/tool-schema turn with role "developer" (the Responses-API equivalent of system used by newer models). Every other system-exclusion guard in this codebase also covers developer (roleNormalizer.ts, contextManager.ts, claudeUpstreamMessages.ts, etc.) except this one, so Headroom happily tabular-compacted JSON arrays embedded in the developer turn (e.g. an update_plan tool schema example), corrupting the instructions the model needs to call the plan tool and breaking Codex CLI plan mode.

Fix: extend the guard in crushMessages()/collectCompactableArrays() (smartcrusher.ts) to skip role === "developer" alongside role === "system".

Reported-by: SingCJ (decolua/9router#2132)
…mpatible Check (port from 9router#2032)

Root cause: validateOpenAICompatibleProvider's chat-completions probe fallback treated ANY 4xx other than 401/403/429/400 as a silent 'credentials valid' pass with no warning, so a bogus/non-standard model id (e.g. Featherless/OpenRouter vendor/model typos) went undetected at Check time. The first real request then hit the upstream 404 model_not_found and the per-model lockout, holding the model unavailable for the configured reset window with no prior indication anything was wrong.

User-visible effect: 'Check' now returns valid:true with an explicit warning (including the upstream error message when parseable) whenever the chat probe answers 404, so a bad model id is caught before it reaches production traffic and the lockout.

Reported-by: advane204f (decolua/9router#2032)
Consistency with the repo's canonical changelog.d/fixes/ workflow (avoids
merge-storm re-conflicts from editing CHANGELOG.md directly).
…mplexity ratchet at baseline

The #1556 lookaround strip walked every sub-schema field with its own
copy-pasted if-block (properties / patternProperties / definitions / $defs,
then prefixItems / anyOf / oneOf / allOf), pushing stripUnsupportedRegexPatterns
past the cyclomatic threshold and check:complexity to 2057 > baseline 2056.

Collapse the eight near-identical blocks into two loops over the field-name
constants, with the object-map recursion factored into a helper. Same fields,
same traversal order, same behavior — complexity is back at baseline 2056 and
the #1556 regression tests still pass.
@mergify mergify Bot closed this Jul 16, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/975719d4e3 branch July 16, 2026 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants