fix(stack): don't treat own cluster's ports as conflicts under --force

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v

[bussyjd]

Problem

obol stack init --force is meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.

stripConflictingPorts / rewriteConflictingPorts only used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g. 80:80, 443:443), those ports looked “in use,” so init rewrote k3d.yaml to ephemeral host ports (e.g. 65002/65003). After recreate, the stack was stuck on non-canonical ports even though --force was reinstalling the same cluster.

Fix

Thread force bool through Backend.Init so the k3d path can apply an ownership exception:

1. Under force, inspect the existing cluster’s load-balancer with docker port k3d-<cluster>-serverlb.
2. Parse published host ports into an owned set (k3dOwnedHostPorts).
3. In rewriteConflictingPorts, keep a mapping when available(hostPort) || owned[hostPort].
4. Genuinely foreign occupants still strip as before; only ports held by the cluster being recreated are exempt.

ensureK3dPortsAvailable (called from Up()) still passes force=false — see Limitations.

Diagram

flowchart TD
A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"]
B --> C["For each default host:container mapping"]
C --> D{"owned by existing cluster?"}
D -->|yes| E["Keep canonical mapping\n(skip strip)"]
D -->|no| F{"host port available?"}
F -->|yes| G["Keep mapping"]
F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"]
E --> I["Recreate cluster on canonical ports"]
G --> I
H --> I

Loading

Validation

gofmt -l internal/stack/backend.go internal/stack/backend_k3d.go internal/stack/backend_k3s.go internal/stack/backend_test.go internal/stack/stack.go internal/stack/stack_test.go
go build ./...
go test ./internal/stack/... -count=1

Actual output:

ok github.com/ObolNetwork/obol-stack/internal/stack	7.130s

(gofmt -l printed nothing; go build ./... succeeded with no output.)

Limitations

• ensureK3dPortsAvailable (the re-check in Up() before a fresh k3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.
• Ownership is detected via the k3d-<cluster>-serverlb Docker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.

---

https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v