one go proxy hiccup made go mod download fail; the agent concluded the module was gone and vendored a stale copy

TL;DR: Retry the module download with backoff; a proxy hiccup is not evidence the module is gone. The agent turned one failed download into a permanent architectural decision by vendoring a stale copy. Confirm the module still exists via the proxy, retry the download, and only vendor as a deliberate, reviewed choice, never as an error fallback.

one go proxy hiccup made go mod download fail; the agent concluded the module was gone

1. Retry the module download with backoff. Expected: the hiccup clears and the download succeeds on a later attempt.

2. Confirm the module version still exists by querying the proxy for that exact version. Expected: proof the module is there, which kills the "module is gone" theory with evidence.

3. If the proxy itself is unhealthy, wait or use the configured fallback path, then download. Expected: a fresh copy of the intended version, not a stale one.

4. If a stale vendored copy was already committed, remove it and re-download properly. Expected: the tree matches the intended module version again.

Use this when

• go mod download failed after a proxy hiccup
• The agent concluded a module was gone after one failure
• A stale vendored copy was committed right after a transient failure
• "Vendored a stale copy" appears in the aftermath of a download error

Not for this skill when

• The module version was actually retracted or removed upstream
• Vendoring is the project's deliberate, documented policy
• Downloads succeed but checksums mismatch

Variant phrasings

• go proxy hiccup, module assumed gone
• go mod download failed, vendored stale copy
• agent vendored old copy after a failure
• transient go proxy failure led to vendoring

Why it happens

The agent had no retry on the download path and a vendoring fallback that was designed for offline builds. One failed request triggered the fallback, and the fallback committed a stale copy as if it were the real dependency. A transient network event got promoted into a permanent tree change.

Edge cases

• Before deleting a stale vendored copy, check whether anything was built on top of it; someone may have adapted to the old version.
• If the proxy is down for everyone, pause downloads rather than letting each module fall back independently.
• Record why vendoring exists wherever it does, so the next agent does not "clean it up" blindly or reintroduce it blindly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstMuioXoDvD77541cegR0rg