fix(relay): reconnect to new networks when routes are unchanged

[ndeloof]

What this PR does, in one sentence

A relay whose identity is still up to date now also gets connected to any network a newly added dependent service needs, instead of silently staying unreachable from it.

Context

relayIdentity (pkg/compose/relay.go) hashes the relay's image and routes only — not the set of networks it's supposed to join. ensureServiceRelay uses that identity to decide whether an existing relay container can be reused as-is: when it matches and the container is already running, it returns immediately.

That's correct for image/route changes, but network membership can change independently: a service added later, depending on the same provider, on a network the relay was never attached to. Since neither the image nor the routes changed, the identity still matches, and the running-container fast path returned without ever looking at whether the relay's current networks still covered every consumer. The new service could never reach the provider at its compose-native address — no error, just silent unreachability.

What this PR brings

ensureRelayNetworks now runs on every reuse path (running, stopped, paused) before the state-specific branch decides what to do with the container: it connects whichever networks the relay isn't already on, using the network membership findRelayContainer's ContainerList call already returned (no extra inspect round-trip). Networks the relay is already connected to are left untouched.

Two tests lock this in: ensureRelayNetworks in isolation (connects only the missing network), and ensureServiceRelay end to end (a running relay with a matching identity gets connected to a new network without being recreated — no ContainerCreate/ContainerStart expected).

🤖 Generated with Claude Code

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

[docker-agent]

[medium] NetworkConnect "endpoint already exists" error not tolerated — spurious failure under concurrent reconciliation

ensureRelayNetworks builds its connected map from the NetworkSettings returned by ContainerList in findRelayContainer. Because compose runs ensureServiceRelay concurrently per provider service, a second goroutine may have already connected the relay to the same network in the window between that snapshot and the NetworkConnect call. When that happens the daemon returns an "endpoint already exists in network" error, which is unconditionally wrapped and returned as a fatal error (line 227), even though the relay is actually in the desired state.

errdefs is already imported (line 31) and used for IsNotFound (line 323). The idiomatic fix is to treat an "already exists" / conflict response as a no-op, consistent with the rest of the relay reconciliation:

Suggested change

	}); err != nil {
	return fmt.Errorf("connect relay for service %s to network %s: %w", service.Name, netName, err)
	}
	}); err != nil && !errdefs.IsConflict(err) {
	return fmt.Errorf("connect relay for service %s to network %s: %w", service.Name, netName, err)
	}

Confidence	Score
🟢 strong	100/100

[codecov]

Codecov Report

❌ Patch coverage is 76.47059% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/compose/relay.go	76.47%	2 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[docker-agent]

Assessment: 🟢 APPROVE

This review covers only the commits pushed since a5e0adc4476c8c05b963305b6662aeb6d3ecdb00.

The incremental change is a single targeted fix: now tolerates an "endpoint already exists" conflict from the Docker daemon when connecting a relay container to a network. This correctly handles the race between concurrent goroutines, where a second goroutine may connect the relay to the same network in the window between the snapshot and the call. Using from github.com/containerd/errdefs (already imported at line 31) is the correct predicate for the daemon's HTTP 409 response. The fix is well-scoped, the comment is accurate, and no issues are introduced.

[docker-agent]

Assessment: 🟢 APPROVE

This review covers only the commits pushed since a5e0adc4476c8c05b963305b6662aeb6d3ecdb00.

The incremental change is a single targeted fix: ensureRelayNetworks now tolerates an "endpoint already exists" conflict from the Docker daemon when connecting a relay container to a network. This correctly handles the race between concurrent ensureServiceRelay goroutines, where a second goroutine may connect the relay to the same network in the window between the ContainerList snapshot and the NetworkConnect call. Using errdefs.IsConflict from github.com/containerd/errdefs (already imported at line 31) is the correct predicate for the daemon's HTTP 409 response. The fix is well-scoped, the comment is accurate, and no issues are introduced.