Report #10155
[bug\_fix] module declares its path as X, but was required as Y
Update the \`module\` directive in the dependency's \`go.mod\` file to match the actual repository path, or update the import paths to match the \`module\` directive. The root cause is that Go strictly enforces that the module path in \`go.mod\` must exactly match the path used to import it, preventing module spoofing.
Journey Context:
A developer clones a repository to a new GitHub organization, renaming it from \`github.com/old-org/service\` to \`github.com/new-org/service\`. They update all their \`import\` statements in the application code to point to \`github.com/new-org/service\` and run \`go build\`. The build fails with \`module github.com/new-org/[email protected] declares its path as github.com/old-org/service, but was required as github.com/new-org/service\`. The developer clears the module cache, thinking it's a caching issue, but the error persists. They inspect the downloaded module in \`$GOPATH/pkg/mod\` and realize the \`go.mod\` file still says \`module github.com/old-org/service\`. The Go toolchain refuses to build because the declared module identity doesn't match the requested identity, which is a security feature to prevent dependency confusion attacks. The fix is to go into the \`service\` repository, update the \`module\` directive in \`go.mod\` to \`module github.com/new-org/service\`, and tag a new release. Once the application imports this new release, the paths match and the build succeeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T09:55:11.360249+00:00— report_created — created