Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

Relationships

#1672 Misleading collective_not_trusted auto-resolve error when a local source extension transiently fails to index during workflow validate

Opened by 4chems · 8/15/2026

Type: Bug Component: extension catalog / local source indexing / swamp workflow validate swamp version: 20260814.171226.0-sha.14540c33 (Linux amd64, installed via curl -fsSL https://swamp.club/install.sh | sh)

Summary

When a model type provided by a local source extension (a checked-in extensions/models/*.ts file, never published to the registry) transiently fails to index — e.g. an npm dependency fetch flake while the bundler inlines npm deps at bundle time — swamp workflow validate silently falls back to registry auto-resolve for that type. Since the collective is a private local namespace, auto-resolve fails with collective_not_trusted, and the validation errors tell the user to pull the extension:

{"event":"auto_resolve","status":"failed","type":"@lakh/node-provisioner","reason":"collective_not_trusted","collective":"lakh"}
...
Model type '@lakh/node-provisioner' could not be resolved — ensure the extension is pulled

Both messages point in exactly the wrong direction: there is nothing to pull and nothing to trust — the real failure was local indexing/bundling, which is never surfaced.

Environment / repro context

  • CI (GitLab), fresh buildpack-deps:bookworm-curl container per job, repo checked out, .swamp/ untracked (recreated from scratch each run).
  • extensions/models/node_provisioner.ts defines @lakh/node-provisioner (local source aggregate @local/operations, origin local). It is referenced by 17 workflow steps.
  • Job script: install swamp, then swamp workflow validate --json.

Observed timeline (2026-08-14, pipeline 6158):

  1. Run on main, 17:xx — green, zero auto_resolve events.
  2. ~25 min later, two runs within ~1 minute — both fail with 17 identical "could not be resolved" errors for @lakh/node-provisioner only, each preceded by the collective_not_trusted auto_resolve event. Same binary, same commit content for the extension file.
  3. Retry a few minutes later — green again, zero auto_resolve events.

The transience plus fresh-container bundling strongly suggests an npm-dep fetch failure during local extension bundling; the bundling/indexing error itself never appeared in the output.

Expected

  • If a type matches a local source extension whose indexing/bundling failed, workflow validate should report that failure (file path + underlying bundler/loader error, like swamp doctor extensions does), and should NOT attempt registry auto-resolve for a type that has a local definition.
  • Auto-resolve fallback for a locally-defined type should at minimum be logged as such ("local source extension X failed to index (); attempting registry auto-resolve"), so the root cause is visible.
  • Ideally: indexing of local sources is retried or fails the command with a distinct, actionable error class instead of a resolution error.

Actual

  • The local indexing failure is swallowed.
  • Validate emits a registry-trust error (collective_not_trusted) and a hint ("ensure the extension is pulled") that cannot apply to local source extensions, sending operators down a registry/trust debugging path.

Impact

Flaky CI failures that masquerade as trust/registry misconfiguration; hard to diagnose because the misleading error is deterministic-looking while the real cause is a transient network/bundling issue. We had to add a signature-matched retry guard to our CI as a workaround.

Workaround in use

CI wraps workflow validate in a guard: on failure, grep for "could not be resolved"; if present, force swamp doctor extensions --json (full catalog rescan), sleep, retry once; otherwise fail immediately.

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

8/15/2026, 7:09:23 AM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.