Skip to content

merge queue: checking release/v3.8.49 (7123236), #7103, #7104, #7105 and #7106 together - #7412

Closed
mergify[bot] wants to merge 14 commits into
release/v3.8.49from
mergify/merge-queue/88e974c344
Closed

mergify[bot] wants to merge 14 commits into
release/v3.8.49from
mergify/merge-queue/88e974c344

Conversation

@mergify

@mergify mergify Bot commented Jul 16, 2026 •

Copy link
Copy Markdown

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

Branch release/v3.8.49 (7123236), #7103, #7104, #7105 and #7106 are queued together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #7106.
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>=1
  • check-success=Merge integrity (changelog + generated skills)
  • any of:
    • #check-failure=0
    • all of:
      • #check-failure=1
      • check-failure=dast-smoke

Required conditions to stay in the queue:

---
checking_base_sha: f3dbee2eac5ce24db2826d213abd8afc69d827db
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 7106
    scopes: []
scopes: []
...

diegosouzapw and others added 14 commits July 13, 2026 23:07
…ort from 9router#2493)

isBetterSqliteBinaryValid() only checked the .node file's magic bytes (ELF/Mach-O/PE header), never whether the binary was built for the ABI (NODE_MODULE_VERSION) of the Node runtime that loads it. A stale or foreign-ABI binary passed the check and then segfaulted the process on the first database call instead of triggering a rebuild via npmInstallRuntime(). The fix adds a real load probe (require() in a throwaway subprocess) after the magic-byte check, so an incompatible binary is now correctly reported as invalid and the runtime self-heal reinstalls it.

Reported-by: Manikandan (@mrprohack) (decolua/9router#2493)
…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)
…port from 9router#2413)

Custom agent clients (e.g. non-OpenCode providers) commonly send X-Session-ID and X-Title headers for upstream request tracking/attribution, but forwardOpencodeClientHeaders() only forwarded x-opencode-* keys plus User-Agent, silently dropping these for every client. Extends the existing case-insensitive allowlist forwarding path with x-session-id/x-title.

Reported-by: Atikur Rahman Chitholian (@chitholian) (decolua/9router#2413)
… 9router#2461)

Root cause: the STREAMING branch of AntigravityExecutor.executeOnce() had no
!response.ok check at all — it unconditionally wrapped the upstream response
body in a pass-through TransformStream, unlike the sibling non-streaming
branch which already built a sanitized error via buildAntigravityUpstreamError.
When Google's 403 error body was binary/non-UTF8 (observed: gzip-magic-byte
payloads), those raw bytes were forwarded verbatim, corrupting the
client-visible error message ('[ERROR] [403]: <control-byte garbage>').

Fix: add the same !response.ok guard to the streaming branch, routing through
buildAntigravityUpstreamError()/buildErrorBody() (hard rule #12) instead of
piping unknown bytes through as if they were an SSE stream.

Reported-by: Duongkhanhtool (decolua/9router#2461)
Consistency with the repo's canonical changelog.d/fixes/ workflow (avoids
merge-storm re-conflicts from editing CHANGELOG.md directly).
Consistency with the repo's canonical changelog.d/fixes/ workflow (avoids
merge-storm re-conflicts from editing CHANGELOG.md directly).
@mergify mergify Bot closed this Jul 16, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/88e974c344 branch July 16, 2026 11:26
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.

1 participant