Skip to content

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

Closed
mergify[bot] wants to merge 12 commits into
release/v3.8.49from
mergify/merge-queue/16cb470b92
Closed

mergify[bot] wants to merge 12 commits into
release/v3.8.49from
mergify/merge-queue/16cb470b92

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 #7100 has been requeued. ✨

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

This pull request has been created by Mergify to speculatively check the mergeability of #7100.
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: 6dd5159236a55b494a81724304f98d9b3287a4bb
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 7100
    scopes: []
scopes: []
...

diegosouzapw and others added 12 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)
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/16cb470b92 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