runWithTimeout previously called t.Fatalf when the timeout fired, but the
executeDelegation goroutine was not cancelled — with context.Background()
it kept running indefinitely (DB ops, broadcaster, etc.). The goroutine
held runtime.LockOSThread(), causing it to leak until the test binary
exited.
Fix: runWithTimeout now creates ctx, cancel := context.WithTimeout(ctx,
timeout), passes ctx to executeDelegation, and calls cancel() when the
timeout fires. The goroutine's blocking calls (db.DB.ExecContext,
conn.Write, etc.) respect the cancelled context and unblock, allowing
the goroutine to exit cleanly. runtime.Goexit() terminates the goroutine
so the main select loop completes.
This also required changing the fn signature from func() to
func(cancel func()) so the cancel function can be propagated.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Commit d60da43c added timeouts using time.Second but neglected to add
the "time" import to the file. The test would not compile without it.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
executeDelegation previously created its own context.Background() with a
30-minute timeout internally, so updateDelegationStatus and all DB ops
ignored external cancellation. The test helper runWithTimeout could fire
its 30-second deadline but the goroutine kept running for the full 30
minutes because the cancellation never propagated.
Fix: add ctx context.Context as first parameter to both executeDelegation
and updateDelegationStatus. The caller now provides the context budget —
Delegate() passes c.Request.Context() (5 min idle timeout), and tests pass
context.Background(). This means runWithTimeout's deadline now actually
terminates the goroutine when it fires.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add 10s timeouts to integrationDB and setupIntegrationFixtures DB
operations, and a 5s timeout to the cleanup DELETEs. The raw TCP
mock server was confirmed working (tests pass in 5-8s when they pass),
but some CI runs hang for 2+ minutes. Adding timeouts ensures that if
DB operations block, the test fails cleanly with a timeout message
rather than hanging the CI job. This also makes the tests more
resilient to transient postgres slowness under CI runner load.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Pin the goroutine to a single OS thread for the duration of
executeDelegation. This provides a second line of defence against the
scheduler-migration race that log.Printf alone sometimes fails to
prevent under heavy CI runner load. In production the pinning is
harmless: the goroutine terminates when the request completes.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The log.Printf calls in executeDelegation are load-bearing for the
integration test surface. Add a comment explaining why: they prevent
Go's compiler from inlining the function, which eliminates a subtle
stack-sharing race between the inlined body and the test goroutine.
Rename "DIAG step=..." to "step=..." to make them proper INFO-level
delegation lifecycle markers rather than debug diagnostics.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The timedExecuteDelegation wrapper was added during DIAG investigation but
is not called by any test. Remove it to keep the test file clean. The
runWithTimeout wrapper from the prior commit remains and guards against
hanging tests consuming the full CI timeout budget.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add log.Printf DIAG markers at each step inside executeDelegation so
the CI log reveals exactly which call is blocking. The previous
runWithTimeout commit captured a stack trace on 30s timeout but the
CI logs were inaccessible (Gitea Actions API 404). This commit
adds coarse-grained timing markers that appear in the test output even
when the test times out — the last DIAG line before the hang tells us
exactly where executeDelegation is blocked.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Wraps every executeDelegation call in a 30-second goroutine timeout
wrapper. When a test hangs, it now fails fast with a goroutine stack
trace instead of consuming the full 5-minute CI timeout. This gives
each of the 5 tests its own diagnostic window and prevents a single
hang from leaving no time for subsequent tests.
The stack trace in the failure output pinpoints the exact blocking
syscall/goroutine so we can identify the root cause without guessing.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Explicitly bind to IPv4 only with net.ListenTCP("tcp4", ...) to
avoid IPv6 (::1) vs IPv4 (127.0.0.1) mismatch on macOS where
Listen("tcp", "127.0.0.1:0") might bind ::1.
- Close the connection immediately after writing the response.
If we keep it open, the client's request-body writer goroutine
blocks on the socket (waiting for server to drain the body).
Closing immediately unblocks it; the client already received
the response so the write error is harmless.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds t.Log statements at each step of test execution to identify
where the hang occurs. Also changes rawHTTPServer from blocking Read
to a 2-second deadline-based read to avoid deadlock where the server
waits for body while client waits for headers.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
All previous approaches (plain httptest.Server, raw TCP with io.Copy,
httptest+Hijack) produced a consistent 2-minute timeout in CI.
Analysis of httptest.Server revealed a subtle goroutine ordering
dependency: the server reads the request body into a buffer before
calling the handler, but the client's request-body writer goroutine
waits for response headers before sending the body. The handler must
return (sending headers) before the client's body writer can complete.
This creates a potential race where the connection is closed while the
client is still writing.
The raw TCP approach eliminates all HTTP library goroutines:
- net.Listen("tcp", "127.0.0.1:0") binds an ephemeral port
- Accept in a goroutine, handle one connection
- Read headers using a 2-second deadline (enough for client to send)
- Send response immediately, close connection
- a2aClient DialContext intercepts all dials and redirects to our port
Key insight: set a Read deadline (not ReadAll to EOF) so the server
proceeds to send the response without waiting for the body. The kernel
discards unread buffered body bytes on close — harmless.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The 2-minute timeout was caused by io.Copy(io.Discard, r.Body) in the
httptest.Server handler. Go's http.Server reads the full request body
into a buffer BEFORE calling the handler, so r.Body is pre-populated.
The io.Copy call itself wouldn't block — but the goroutine lifecycle
creates a subtle ordering dependency: the handler must return to send
response headers, which unblocks the client's body-writer goroutine,
which then tries to write remaining body bytes to a potentially-closed
connection.
Fix: remove io.Copy from the handler entirely. The httptest.Server
already consumed the body. Just write the response and return.
Also: add missing net/net/url imports, remove unused agentServer/setupIntegrationRedis
helpers, restore allowLoopbackForTest(t) calls (SSRF guard), inline
httptest.Server creation per-test, override a2aClient DialContext to
redirect all connections to the test server.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Content-Length mismatch (declared > actual) causes the HTTP transport to wait
for the remaining bytes. After the TCP keepalive (~2 min), it returns a
ProtocolError — indistinguishable from a genuine transport failure. The test
then runs for 1m57s before failing.
Fix: set declaredLength = len(actualBody) in all test cases. The
partial-body delivery-confirmed scenarios are covered by the sqlmock tests
in delegation_test.go; these integration tests verify DB row state after
clean success/failure paths.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Abandons raw TCP mock and httptest+Hijack in favour of plain httptest.Server.
Both prior approaches caused deadlocks:
- Raw TCP: server read vs client write pipelining caused both sides to block.
- httptest+Hijack: Go's HTTP server keeps a request-read goroutine active after
Hijack; if request body hasn't been fully received, Hijack() blocks waiting for
it while the client blocks waiting for response headers — mutual deadlock.
Plain httptest.Server accepts connections cleanly, sends responses, and closes
normally — the Go HTTP/1.1 client reads available bytes then gets EOF when the
server closes the connection. Content-Length mismatch (declared > actual) simulates
partial-body connection-drop scenarios without any TCP manipulation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Previous raw TCP approach drained the request body FIRST, then sent the
response. This caused a deadlock:
Server: waiting to READ request body (blocking on conn.Read)
Client: waiting for RESPONSE HEADERS (blocking on conn.Read from server)
Neither can proceed — the client's request-body write is blocked waiting
for response headers, so the server never receives the body, so the drain
never completes, so the server never sends the response.
Fix: send the response FIRST. The client's response-reader unblocks (gets
response), so the client's request-body writer can complete and send the
body. The drain goroutine then reads whatever the client sent. The
server closes the connection while the drain is in progress — fine, the
drain goroutine just gets a connection-closed error and exits.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Abandon httptest+Hijack — it has two fundamental problems for this use case:
1. Buffered-writer loss: httptest's Hijack() discards the buffered writer,
losing any bytes written via w.WriteHeader/w.Write that weren't already
flushed to the raw conn. The HTTP client never receives response headers,
blocking on ResponseHeaderTimeout=180s (the 2m8s hang).
2. Request-read deadlock: Go's httptest server keeps a read goroutine waiting
for the request body after the handler returns. Calling Hijack() while that
goroutine is still waiting causes a deadlock with the client's request-body
writer.
Fix: use raw TCP with net.Listener directly. The server:
1. Accepts one connection.
2. Reads HTTP request headers (blank line terminates).
3. Drains Content-Length bytes from the connection (prevents broken-pipe on
client request-body writer when we close).
4. Writes raw HTTP response directly to the raw conn (no buffered writer).
5. Brief sleep so client reads headers+body before FIN fires.
6. Close() sends FIN → client Read() returns io.EOF.
Also add allowLoopbackForTest() to each test so the SSRF guard permits
127.0.0.1 mock server URLs (same pattern as a2a_proxy_test.go).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Root cause of the 2m8s hang (which matched ResponseHeaderTimeout=180s):
httptest's Hijack() discards the buffered writer, losing any bytes written
via w.WriteHeader/w.Write that weren't already flushed to the raw TCP conn.
The HTTP client therefore never receives response headers, blocking on
ResponseHeaderTimeout (3 min).
Fix: write the raw HTTP response directly to the raw conn AFTER Hijack(),
completely bypassing httptest's buffered writer. This ensures:
- Response headers reach the client immediately (not lost to buffered writer)
- Client starts reading the response body
- conn.Close() fires while client is mid-read → Read() returns EOF/error
- executeDelegation completes in seconds, not minutes
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Closing r.Body triggers the Go HTTP server's pipe mechanism to signal EOF
to the request-body reader. On the CLIENT side, this causes the
request-body writer goroutine to fail with "read from closed pipe", which
hangs the HTTP request indefinitely (until TCP-level timeouts fire).
Fix: remove all r.Body access. Just Hijack() + conn.Close() and return.
Matching the exact pattern from a2a_proxy_test.go
TestProxyA2A_BodyReadFailure_DeliveryConfirmed.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The previous httptest.Server implementation called io.Copy(io.Discard, r.Body)
before Hijack(), which caused a 3-minute hang: the handler blocked waiting
to finish reading the request body while the HTTP client was blocked writing
the body (waiting for response headers that the handler hadn't sent yet).
This is a classic deadlock.
Fix: match the existing a2a_proxy_test.go pattern — do NOT read r.Body
before Hijack(). The HTTP parser has already consumed request headers; the
body may still be in flight from the client. The server closes r.Body when
the handler returns (server-managed), and conn.Close() after Hijack() fires
RST/EOF to the client, which is the desired "connection drop" simulation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The raw TCP mock servers used in tests 1-3 caused 5-minute CI timeouts.
The issue was two-fold:
1. defer conn.Close() fired before the kernel TCP send buffer was drained,
so HTTP headers never reached the client and it blocked forever waiting.
2. Even with an explicit 200ms sleep before Close(), the CI environment
under load sometimes didn't drain the buffer in time, causing the
5-minute idle timeout (A2A_IDLE_TIMEOUT_SECONDS) to fire.
Switch to httptest.Server with http.Hijack():
- httptest.Server handles the HTTP listener lifecycle properly.
- Hijack() gives direct access to the raw TCP connection after HTTP headers
are parsed, bypassing the buffered writer.
- Flush() before Hijack() ensures data reaches the kernel TCP buffer.
- Immediate conn.Close() after Flush() triggers a read error on the HTTP
client (connection reset / EOF) even though headers arrived.
This matches the pattern already proven in a2a_proxy_test.go for similar
partial-body connection-drop scenarios.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bug: raw-TCP mock servers in integration tests used
`defer conn.Close()` which fires immediately after `conn.Write`
(buffered in kernel send buffer). The connection closed before the
kernel TCP stack finished transmitting the response, so the Go HTTP
client hung waiting for response headers that never arrived.
Test 1 (200 + partial body) timed out at the 5-minute idle timeout:
- mock server: Accept → Read → Write(135B) → defer Close → goroutine exits
- client: sent request, waited forever for response headers
- isDeliveryConfirmedSuccess path never reached
Tests 2-3 (500 / empty body) passed in 500ms because the 500ms
test-body-timeout caught the hanging goroutine. Fix is the same for
all three: write the response, sleep 200ms (kernel TCP transmits),
*then* close.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Root cause of 5-minute timeout: setupIntegrationRedis seeded Redis with
http://bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb (the UUID as hostname), which
the Go http.Client cannot resolve. The SSRF validation passes (valid DNS
hostname) but DNS resolution fails → HTTP request hangs for the client's
default 60s timeout before retrying → test times out at 5m.
Fix: change setupIntegrationRedis(t) → setupIntegrationRedis(t, agentURL)
so each test passes the actual mock server address (http://127.0.0.1:PORT)
before the function caches it. Remove the redundant db.RDB.Set override in
Test1 (URL now correct from the start).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
RecordAndBroadcast (called by executeDelegation) calls db.RDB.Publish(),
which panics when db.RDB is nil.
Fix:
- Add setupIntegrationRedis() helper that starts miniredis, sets db.RDB,
and seeds the target workspace URL via db.CacheURL
- Call setupTestRedis() directly in the Redis-down test (no URL cached,
so resolveAgentURL falls back to DB which also has no URL → target
unreachable)
- Import db and redis packages
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
workspaces.id is UUID-typed. The string IDs like "ws-source-159-integration"
caused: pq: invalid input syntax for type uuid
Fix: use real UUIDs (AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA /
BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB) matching the pattern in
delegation_ledger_integration_test.go.
Also add the required 'name' column (NOT NULL) to the INSERT.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Both packages were imported but not referenced in the file.
Go build tag "integration" still compiles them — caught by CI.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Line 443 of mcp.go concatenated user-controlled req.Method into the
JSON-RPC -32601 error message, allowing an agent or canvas client to
inject arbitrary strings into the response via the method field.
Fix: replace "method not found: " + req.Method with the constant
"method not found" — matching the OFFSEC-001 scrub contract applied
to the InvalidParams (line 428) and UnknownTool (line 433) paths.
Test: extend TestMCPHandler_UnknownMethod_Returns32601 with two new
assertions:
1. resp.Error.Message == "method not found"
2. defence-in-depth check that the sent method name never appears
in the response (strings.Contains guard)
Issue: #684
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
executeDelegation(sourceID, targetID) fires proxyA2ARequest which calls
registry.CanCommunicate(sourceID, targetID) when source != target. Both
IDs are different test fixtures (ws-source-159, ws-target-159), so the
lookup fires two separate getWorkspaceRef queries:
SELECT id, parent_id FROM workspaces WHERE id = $1 -- sourceID
SELECT id, parent_id FROM workspaces WHERE id = $1 -- targetID
expectExecuteDelegationBase only mocked the URL/status fallback query.
sqlmock would fail with "unexpected query" when the CanCommunicate
lookups fired — this was a silent failure because the tests never
verified ExpectationWereMet on the CanCommunicate path.
Fix: add two ExpectQuery rows for both parent_id lookups (both NULL,
root-level siblings, allowed).
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Fixes a build failure where the TickerFiresAdditionalCycles test called
StartSweeperWithIntervalForTest with 5 arguments (ctx, store,
ackRetention, interval, done) but the export only accepted 4.
Also fixes a pre-existing vet error in org_external.go: a no-op
`append(gitArgs(...))` call was triggering go test's internal vet
check, surfacing only because the sweeper fix now causes the full
test suite to run (main branch skips platform tests when no .go files
change, completing in 10s vs 14min for the full suite).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
TestStartSweeperWithInterval_TickerFiresAdditionalCycles was flaky on
loaded CI runners because it called StartSweeperForTest, which passes
SweepInterval (5 minutes) as the ticker interval. The test expects ≥2
cycles in a 2-second window, but a 5-minute ticker fires 0-1 times
under CPU contention, causing "waited 2s for 2 sweep cycles, got 1".
Fix: call StartSweeperWithIntervalForTest directly with a 100ms ticker
interval, which is the intended test-harness pattern (per the export_test
comment). The done-channel teardown (cancel + <-done) is preserved.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
loadWorkspaceEnv returns map[string]string but EnvRequirement.IsSatisfied
expects map[string]struct{}. Without this conversion the Go compiler
rejects the call, causing CI / Platform (Go) to fail.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Before returning 201 on /org/import, verify that every RequiredEnv
declared at the workspace level is covered by either:
(a) a global secret key (already validated by the existing preflight)
(b) a key present in the workspace's .env files (org root .env +
per-workspace <files_dir>/.env), matching the resolution order
used by createWorkspaceTree at runtime
Previously, collectOrgEnv correctly walked all
tmpl.Workspaces[].RequiredEnv and added them to the global preflight
check, but loadConfiguredGlobalSecretKeys only checked global_secrets.
Workspace-specific .env files are injected into workspace_secrets AFTER
the 201 response, so an unsatisfied per-workspace RequiredEnv returned
201 and the workspace came up NOT CONFIGURED — breaking on every LLM
call with no signal to the operator.
Changes:
- org_import.go: add PerWorkspaceUnsatisfied struct +
collectPerWorkspaceUnsatisfied (mirrors createWorkspaceTree's
three-source .env resolution stack)
- org.go: after the global preflight block, call
collectPerWorkspaceUnsatisfied if orgBaseDir != ""; return 412
with per-workspace details before creating any workspaces
- org_workspace_required_env_test.go: 8 unit tests covering global
coverage, .env coverage, missing keys, any-of groups, nested
children, empty orgBaseDir, and multiple workspaces
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
checkToolOnPath must match the checkTool func(tool string) error
signature in LocalBuildOptions — Go does not allow assigning a function
with (string, error) returns to a func(string) error variable.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Before reaching the clone/build cold path, check that both `docker` and
`git` are on PATH. Previously, a missing `docker` would produce a
cryptic "exec: docker: executable file not found" from deep inside the
docker-has-tag or docker-build call. Now the error surfaces immediately
with:
local-build: "docker" not found on PATH — local-build mode requires
both docker and git; either install them, or set MOLECULE_IMAGE_REGISTRY
so local-build is bypassed
The check runs before the cache-hit fast path too, since docker is used
for image inspect + tag even on a cache hit.
Adds checkTool seam to LocalBuildOptions so tests can inject a stub
(no-op in makeTestOpts; two new tests exercise the missing-tool path).
Fixes issue #529 option B.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add deferred error checks following rows.Next() iteration in:
- ListDelegations (delegation.go): log on error, continue serving results
- org import reconcile orphan query (org.go): log + append to reconcileErrs
Fixes the rows.Err() gap identified in the delegated rows.Err() check PR
(#302, closed; replaced by this PR). Two additional files already had
the check (activity.go, memories.go) — pattern applied consistently here.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two vulnerable call sites confirmed on origin/main:
1. org_helpers.go:loadWorkspaceEnv (line 101): filesDir from untrusted org YAML
joined directly with orgBaseDir without traversal guard. A malicious filesDir
like "../../../etc" escapes the org root and reads arbitrary files.
2. org_import.go:createWorkspaceTree (line 494): same pattern directly in the
env-loading block — not covered by staging-targeted PR #345.
Fix (both locations): call resolveInsideRoot(orgBaseDir, filesDir) before
filepath.Join. On traversal detection, org_helpers.go returns an empty map
(caller contract); org_import.go silently skips the workspace .env override
(matches existing template-resolution pattern in the same function).
Tests: org_helpers_test.go — 3 cases covering traversal rejection,
workspace-override happy path, and empty filesDir edge case.
Closes: molecule-core#362, molecule-core#321
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The Molecule-AI GitHub org was suspended 2026-05-06; canonical SCM is
now git.moleculesai.app. external_connection.go was still emitting
github.com URLs in operator-facing copy-paste blocks, breaking
external-agent onboarding silently.
Per-site decisions (8 emit sites in 1 file):
- L124 (channel template doc comment): swap source-of-truth comment to
Gitea host.
- L137 /plugin marketplace add Molecule-AI/...: swap to explicit Gitea
HTTPS URL form. End-to-end-verified path per internal#37 § 1.A.
- L138 /plugin install molecule@molecule-mcp-claude-channel: marketplace
name is molecule-channel (per remote .claude-plugin/marketplace.json),
not the repo name. Fix to molecule@molecule-channel.
- L157 --channels plugin:molecule@molecule-mcp-claude-channel: same
marketplace-name fix.
- L179 user-facing GitHub URL: swap to Gitea.
- L261 pip install git+https://github.com/Molecule-AI/molecule-sdk-python:
not on PyPI; swap to git+https://git.moleculesai.app/molecule-ai/...
- L310 hermes-channel doc comment: swap source-of-truth comment.
- L339 pip install git+https://github.com/Molecule-AI/hermes-channel-molecule:
not on PyPI; swap to Gitea.
- L369 issue-tracker URL: swap to Gitea.
Verification:
- molecule-ai-workspace-runtime, codex-channel-molecule are on PyPI (200);
no swap needed for those pip lines (they were already package-name form).
- molecule-mcp-claude-channel, molecule-sdk-python, hermes-channel-molecule
are NOT on PyPI; swapped to git+https://git.moleculesai.app/molecule-ai/
form. All three repos are public on Gitea (default branch main) and
serve git-upload-pack unauthenticated (verified curl 200 against
/info/refs?service=git-upload-pack).
- Third-party github URLs (gin import, openai/codex, NousResearch/
hermes-agent upstream issue trackers, npm @openai/codex) intentionally
preserved.
Adds TestExternalTemplates_NoBrokenMoleculeAIGitHubURLs regression guard
to prevent the same broken URLs from re-emerging on future template
edits.
go vet / go build / existing TestExternal* — all clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two surfaces in workspace-server hardcoded `ghcr.io` and silently bypassed
the `MOLECULE_IMAGE_REGISTRY` env override that flips every other image
operation to the configured private mirror (e.g. AWS ECR in production):
1. internal/imagewatch/watch.go — image-auto-refresh polled
`https://ghcr.io/v2/...` and `https://ghcr.io/token` directly. Post-
suspension, with the platform pointed at ECR, the watcher silently
stopped seeing digest changes (every poll either 404'd or hung on a
registry it has no business talking to).
2. internal/handlers/admin_workspace_images.go — Docker Engine auth
payload pinned `serveraddress: "ghcr.io"`, so when the operator sets
`MOLECULE_IMAGE_REGISTRY=…ecr…/molecule-ai` the engine matched the
wrong credential entry on every authenticated pull.
Fix: extract `provisioner.RegistryHost()` returning the host portion of
`RegistryPrefix()` (e.g. `ghcr.io` ← `ghcr.io/molecule-ai`, or
`004947743811.dkr.ecr.us-east-2.amazonaws.com` ← the ECR mirror prefix),
and route both surfaces through it. Default behavior is unchanged for
OSS users on GHCR.
Tests
- New `TestRegistryHost_SplitsHostFromOrgPath` and
`TestRegistryHost_NeverEmpty` pin the helper across GHCR / ECR /
self-hosted Gitea / bare-host edge cases.
- New `TestGHCRAuthHeader_RespectsRegistryEnv` asserts the Docker auth
payload's `serveraddress` follows MOLECULE_IMAGE_REGISTRY (and never
leaks the org-path suffix).
- New `TestRemoteDigest_RegistryHostFollowsEnv` stands up an httptest
server, points MOLECULE_IMAGE_REGISTRY at it, and confirms both the
token endpoint and the manifest HEAD land there — i.e. the full image-
watch loop respects the env override end-to-end.
Both new tests were verified to FAIL on the pre-fix code path before the
helper was wired in, so a future revert can't silently re-introduce the
bug.
Out of scope (followup needed)
ECR uses `aws ecr get-authorization-token` (SigV4 + basic-auth) instead
of GHCR's `/token?service=…&scope=…` flow. This PR makes the URL host-
configurable; the bearer-token negotiation in `fetchPullToken` still
speaks the GHCR flavor. On ECR with `IMAGE_AUTO_REFRESH=true`, the
watcher will now fail loudly at the token fetch (logged per tick) rather
than silently hitting ghcr.io. Operators on ECR should keep
IMAGE_AUTO_REFRESH=false until ECR auth is wired — tracked as a separate
task. Net effect of this PR alone is strictly better than pre-fix:
fail-loud > silent-broken.
Refs: RFC #229 P2-4
tier:low
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
internal#226 follow-up #1. `molecule_runtime.config` resolves the picked
model as `MOLECULE_MODEL` > `MODEL` > (legacy) `MODEL_PROVIDER` (#280) —
this side of the boundary now matches:
- applyRuntimeModelEnv reads `MOLECULE_MODEL` ahead of `MODEL` /
`MODEL_PROVIDER`, and exports BOTH `MOLECULE_MODEL` and `MODEL`
(the latter kept for back-compat with everything that already reads
`os.environ["MODEL"]`). So a workspace whose secrets carry
`MOLECULE_MODEL` (the unambiguous name) is honoured, and the
`MODEL_PROVIDER` misnomer — which got set to provider slugs
("minimax") and even runtime names ("claude-code") — is the lowest-
priority fallback, exactly as on the runtime side.
- the resolution-order comment is updated to flag MODEL_PROVIDER as the
legacy-and-misleadingly-named var.
Also drops a stray trailing `}` in delegation_test.go (committed in
97768272 "test(delegation): add isDeliveryConfirmedSuccess helper") that
made `internal/handlers` fail to parse — one of the things keeping the
package from compiling for tests.
Tests: TestApplyRuntimeModelEnv_SetsUniversalMODELForAllRuntimes extended
to assert MOLECULE_MODEL mirrors MODEL on every case, plus two new cases
(MOLECULE_MODEL env fallback; MOLECULE_MODEL beats MODEL_PROVIDER). Could
not run `go test ./internal/handlers/` locally — the package is still
blocked behind `internal/plugins` `SourceResolver` redeclaration (the
#248 plugin-router/resolver refactor, Core-BE's lane); CI validates once
that lands. The applyRuntimeModelEnv change is mechanical (same shape as
the existing `MODEL` handling) — reviewer please eyeball.
Companion: molecule-core#280 (runtime config.py side), molecule-ai-workspace-template-claude-code#14 (CLI-stream-error surfacing).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PR #256 introduced PluginResolver to break the SourceResolver redeclaration
deadlock, but missed three downstream call-sites that left main uncompilable:
1. plugins/drift_sweeper.go: PluginResolver.Resolve was declared returning
PluginResolver (recursive). *Registry.Resolve returns the production
SourceResolver from source.go, so *Registry didn't satisfy PluginResolver.
Fix: Resolve returns SourceResolver. Add compile-time assertion that
*Registry satisfies PluginResolver so any future signature drift fails
the build instead of router wiring.
2. plugins/drift_sweeper_test.go: stubResolver was still declared with the
old SourceResolver shape AND asserted against SourceResolver — the
assertion failed because stubResolver lacks Scheme()/Fetch(). Fix: stub
is a PluginResolver; assertion targets PluginResolver. Drop the unused
"database/sql" import that fails go vet.
3. router/router.go:
- The 70f84823 reorder moved the plgh init block above its dockerCli
dependency (line 538 used; line 594 declared). Moved the dockerCli
declaration up so it's available where used; replaced the orphaned
declaration in the terminal block with a comment.
- Setup's pluginResolver param was typed plugins.SourceResolver — wrong
for *plugins.Registry (Registry is not a per-scheme resolver). Retyped
to plugins.PluginResolver, which *Registry actually satisfies.
- Removed the broken `plgh.WithSourceResolver(pluginResolver)` call —
WithSourceResolver expects a per-scheme SourceResolver, not a
PluginResolver/registry. plgh has its own internal default registry
(github+local) from NewPluginsHandler, so dropping the call is
functionally a no-op vs the broken state. Kept the param so the
drift sweeper (main.go) can share scheme enumeration when needed.
4. go.sum: add the content hash entry for go.moleculesai.app/plugin/
gh-identity/pluginloader (only the /go.mod hash was present, breaking
`go build ./cmd/server`).
Verified locally:
go build ./... ✓
go vet ./... ✓ (only pre-existing org_external append warning)
go test ./internal/plugins/... ✓
go test ./internal/router/... ✓
6 pre-existing handler test failures (TestExecuteDelegation_*,
TestHandleDiagnose_*) are orthogonal — they did not run before because the
package didn't compile. Out of scope for this fix; tracking separately.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
