[release-3.6] Hiding client/v2 causes dependency problem for applications which are depending on go.etcd.io/etcd/server/v3

[ahrtr]

Bug report criteria

• This bug report is not security related, security issues should be disclosed privately via etcd maintainers.
• This is not a support request or question, support requests or questions should be raised in the etcd discussion forums.
• You have read the etcd bug reporting guidelines.
• Existing open issues along with etcd frequently asked questions have been checked and this is not a duplicate.

What happened?

In release-3.6, the client/v2 was changed into an internal package in #15591. But the problem is that client/v2 is still used by v2discovery in etcd/server. So it's causing the dependency problem (see below) for any applications which are using go.etcd.io/etcd/server/v3

$ go get go.etcd.io/etcd/server/[email protected]
go: downloading go.etcd.io/etcd/server/v3 v3.6.0-rc.2
go: go.etcd.io/etcd/server/[email protected] requires go.etcd.io/etcd/client/[email protected]: missing go.etcd.io/etcd/client/go.mod and .../v2/go.mod at revision client/v2.306.0-rc.2

Two possible solutions that I can think of for now:

• [preferred] either revert the change (do not hide client/v2 in 3.6);
• decommission the v2discovery in release-3.6. But it may break the existing users which are still using the deprecated v2discovery.

cc @liggitt @fuweid @serathius @ivanvc

What did you expect to happen?

It shouldn't break any user applications

How can we reproduce it (as minimally and precisely as possible)?

see above

Anything else we need to know?

No response

Etcd version (please run commands below)

$ etcd --version
# paste output here

$ etcdctl version
# paste output here

Etcd configuration (command line flags or environment variables)

paste your configuration here

Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)

$ etcdctl member list -w table
# paste output here

$ etcdctl --endpoints=<member list> endpoint status -w table
# paste output here

Relevant log output

[liggitt]

I'm very confused how the dependency at https://github.com/etcd-io/etcd/blob/v3.6.0-rc.2/server/go.mod#L31 is working for anything ... no such module exists or is resolvable:

go.etcd.io/etcd/client/v2 v2.306.0-rc.2

https://github.com/etcd-io/etcd/tree/client/v2.306.0-rc.2/client has no go.mod or v2/go.mod file ... that's required for that module at that tag to exist

edit: oh... it's working when building the main server binary because the replace directive resolves locally: https://github.com/etcd-io/etcd/blob/v3.6.0-rc.2/server/go.mod#L85

that will only work when building the server main binary, it will break when go is resolving the server dependency graph

[ahrtr]

I'm very confused how the dependency at https://github.com/etcd-io/etcd/blob/v3.6.0-rc.2/server/go.mod#L31 is working for anything ... no such module exists or is resolvable:

Copied my response here:

It does exist. The problem is that it's internal, so it can't be used by module outside the repo

etcd/client/internal/v2/go.mod

Line 1 in 2733667

module go.etcd.io/etcd/client/v2

[liggitt]

but locating that there means Go cannot resolve the module at the given repo+tag, so it doesn't exist from Go's perspective in a resolvable way

[ahrtr]

but locating that there means Go cannot resolve the module at the given repo+tag, so it doesn't exist from Go's perspective in a resolvable way

Yes, it's correct. It works because the replace directive .

[liggitt]

Yes, it's correct. It works because the replace directive .

Go ignores replace directives when dependencies outside the main module, so it also has to exist as a resolvable module+version, not just locally at a hidden path, since the server module is used as a library, not just as a container for the main server binary.

[ahrtr]

Go ignores replace directives when dependencies outside the main module, so it also has to exist as a resolvable module+version, not just locally at a hidden path

Right. I was saying the reason why we did not see this issue ourself is because of the replace directive.

Let me deliver a PR to rollback #15591

[ahrtr]

Already resolved, and the fix will be included in v3.6.0-rc.3 (hopefully to be out tonight).

[serathius]

I think it would be good to also include this change on main branch. It might be easy to forget differences between branches, so it's worth doing even if we will just clean it up in the future

[ahrtr]

even if we will just clean it up in the future

We will clean it up after 3.6.0 is out (e.g. May 2025). It's just a couple of minutes effort.

[serathius]

SG

[ivanvc]

Heads up that v3.6.0-rc.3 is out now. Should we close this issue? Or do we want to keep it open because of #19670 (comment)?

[ahrtr]

Let's close this ticket, the v2 cleanup has already been tracked in #12913