fix(ci): stop the Windows recovered-panic heap crash and the Pass-2 temp-dir race - #1288
Merged
Merged
Conversation
A controller that reports success without a server config (the test doubles do) was dereferenced in handleAddFromRegistry; chi's recoverer turned the fault into a bare 500. Under Go 1.26 on windows/amd64 the recovered hardware exception corrupts the Go heap (golang/go#81238), so the internal/httpapi test binary died later with "found pointer to free object" / "unexpected fault address" on unrelated PRs (#1282, #1285). Return a JSON 500 instead, the way redactedRegistrySummary already tolerates a nil entry, and pin it with a test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deploying mcpproxy-docs with
|
| Latest commit: |
841bcb4
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://dc6ebae2.mcpproxy-docs.pages.dev |
| Branch Preview URL: | https://fix-httpapi-registry-add-nil.mcpproxy-docs.pages.dev |
TestServiceStartScanDeepOnRunsSourceResolutionAndPass2 failed on ubuntu CI with "TempDir RemoveAll cleanup: directory not empty": the Pass-2 goroutine writes tools.json into the server working dir after ResolveFullSource returns and before it registers its engine job, so an idle engine can mean "Pass 1 cleared, Pass 2 not started yet" and the test's teardown raced the write. Wait for the Pass-2 job to reach a terminal status in storage (its last write on every exit path) first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
📦 Build ArtifactsWorkflow Run: View Run Available Artifacts
How to DownloadOption 1: GitHub Web UI (easiest)
Option 2: GitHub CLI gh run download 35112724985 --repo smart-mcp-proxy/mcpproxy-go
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Dumbris
added a commit
that referenced
this pull request
Sep 16, 2026
…1288) This branch diverged from main before #1288 landed, so PR-B's CI hit the exact regression it fixed: handleAddFromRegistry's success path dereferenced a nil cfg, chi's recoverer turned the panic into a bare 500, and the recovered hardware fault corrupted the Go heap on windows/amd64 under Go 1.26 (golang/go#81238) — the internal/httpapi test binary crashed with "found pointer to free object" and took the whole Windows unit-test job (and the binaries job's httpapi/scanner test bundle) down with it. Cherry-picked the same fix main already carries: the nil-config guard with a JSON 500 (and its pinning test), plus the unrelated Pass-2 temp-dir teardown race fix in the scanner test this same upstream commit bundled. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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
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.
Why
Two CI failures that hit Spec 105 PRs (#1282, #1284, #1285) without those PRs touching the code that failed:
internal/httpapi(fatal error: found pointer to free object,unexpected fault address 0xffffffffffffffffwith a garbage stack). Root cause:TestMutatingServerRoutes_AdminAllowed/registry-add-serverdriveshandleAddFromRegistrywith a controller stub that returnsnil, nil, nil; the handler dereferencedcfg.Name, chi's recoverer swallowed the nil-pointer panic and the test passed on every OS. Under Go 1.26 on windows/amd64 the recovered hardware exception corrupts the Go heap (golang/go#81238), so the test binary dies at a later GC — intermittently, on whichever PR runs next.TestServiceStartScanDeepOnRunsSourceResolutionAndPass2:TempDir RemoveAll cleanup: directory not empty. The Pass-2 goroutine writestools.jsoninto the server working dir afterResolveFullSourcereturns and before it registers its engine job, sowaitForScanIdlecan return in the "Pass 1 cleared, Pass 2 not yet started" window and teardown races the write (known rerun-clearable flake since 2026-08-31).What
handleAddFromRegistry: a nil config on the success branch is a JSON 500 (registry returned no server configuration), mirroring the nil-toleranceredactedRegistrySummaryalready has;TestAddFromRegistry_NilConfigIsAnErrorpins it (fails onmainwith the recovered panic). A fullinternal/httpapirun now logs zero recovered panics.waitForScanIdle.-race -count=20, also underGOMAXPROCS=1: green.🤖 Generated with Claude Code