merge queue: checking release/v3.8.49 (7123236), #7104, #7105, #7106, #7116 and #7117 together - #7418
Closed
mergify[bot] wants to merge 19 commits into
Closed
mergify[bot] wants to merge 19 commits into
mergify[bot] wants to merge 19 commits into
Conversation
…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)
…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).
…s (port from 9router#1811) parseInnerCall only split arg segments on a newline between the arg name and its value. Cursor's live Composer/Auto output has been observed using a single space instead, so those segments were treated as one long (space-containing) arg name with an empty value, silently no-opping Write/tool calls for Composer/Auto models. Fall back to splitting on the first whitespace boundary when no newline is present in the segment. Reported-by: way-art (decolua/9router#1811)
… (port from 9router#1809) stopMitm() killed the spawned MITM server process first and only removed the /etc/hosts DNS-spoof entries afterward. During that window any client whose DNS still resolved a target host to 127.0.0.1 but whose MITM listener was already dead got connect ECONNREFUSED 127.0.0.1:443 — exactly the community-confirmed workaround (stop DNS before stopping the server) proves. Swap the two steps so DNS is always cleared first, mirroring the ordering already used by repairMitm() and handleExitCleanup(). Reported-by: dionisius95 (decolua/9router#1809)
… file-size cap The #1809 DNS-before-kill ordering fix pushed src/mitm/manager.ts to 813 lines, over the 800-line cap check:file-size enforces for non-frozen files. Move the pure repair-planning pieces (collectManagedHosts, the RepairPlan shape and its filesystem/cert/DNS sweep) into a sibling src/mitm/repair.ts. The in-memory session bookkeeping repairMitm() owns — cached sudo password, orphaned flag, PID file — deliberately stays in manager.ts, so the seam is "plan the repair" vs "own the session". manager.ts is now 731 lines; behavior is unchanged. The DNS-first ordering fix and its regression guard (tests/unit/mitm-stop-dns-before-kill-1809.ts) are untouched and still pass.
…regression stopMitm()'s new DNS-before-kill ordering (#1809) pushed its cyclomatic complexity to 18 (max 15), regressing the complexity ratchet from 2056 to 2057. Extract the DNS-removal step and the process-kill step (in-memory + PID-file fallback) into two private helpers, mirroring the existing performRepairSteps() extraction pattern in repair.ts. Behavior unchanged; complexity back at 2056 (cognitive-complexity drops to 889, one under baseline).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
✨ Pull request #7105 ahead in the queue was removed (reason:
checks failed). The pull request #7117 has been requeued. ✨Branch release/v3.8.49 (7123236), #7104, #7105, #7106, #7116 and #7117 are queued together for merge.
This pull request has been created by Mergify to speculatively check the mergeability of #7117.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.
Required conditions of queue rule
releasefor merge:#check-pending=0#check-success>=1check-success=Merge integrity (changelog + generated skills)#check-failure=0#check-failure=1check-failure=dast-smokeRequired conditions to stay in the queue:
-conflict-draftbase~=^release/v\d+\.\d+\.\d+$label=queue