Skip to content

Release devloop 0.10.4 - #16

Merged
pasunboneleve merged 3 commits into
mainfrom
fix/6z5h-port-collision
Sep 1, 2026
Merged

Release devloop 0.10.4#16
pasunboneleve merged 3 commits into
mainfrom
fix/6z5h-port-collision

Conversation

@pasunboneleve

Copy link
Copy Markdown
Owner

Summary

  • fail startup once when a managed process's loopback HTTP readiness address is occupied
  • preserve concurrent devloop sessions and worktrees on distinct ports
  • keep startup cleanup and runtime restart-policy behavior explicit through workflow origin
  • publish the fix as devloop 0.10.4

Failure behavior

The colliding session exits non-zero with one diagnostic naming the managed process and address. It does not enter an automatic restart loop, and the existing listener remains untouched. Non-collision workflow failures and later runtime workflows retain degraded-mode recovery and configured restart behavior.

Validation

  • cargo fmt --check
  • cargo test — 169 unit tests plus 12 integration tests passed
  • cargo clippy --all-targets --all-features -- -D warnings
  • env -u RUST_LOG ./scripts/ci-smoke.sh
  • cargo test --test port_collisions -- --nocapture — IPv4 collision, IPv6 collision, and distinct OS-assigned port concurrency passed
  • ./scripts/release-notes-from-changelog.sh 0.10.4 pasunboneleve/devloop
  • cargo run --quiet --bin devloop -- --versiondevloop 0.10.4
  • cargo run --quiet --bin devloop -- --help

Roborev jobs 242 and 245 completed and were accounted for in Kata 6z5h.

Context:
Two devloop sessions could target the same managed server port. The second
session repeatedly restarted its failed child and kept the watcher alive,
leaving an unhealthy supervisor on the occupied address.

Decision:
Treat a loopback HTTP readiness endpoint as the named process's owned startup
address. Check bind availability before launch, classify a post-launch bind
race with the same typed error, suppress startup restart effects, clean up the
attempted session, and exit non-zero with one filter-independent diagnostic.
Preserve concurrent sessions on OS-assigned or otherwise distinct ports.

Alternatives considered:
A repository singleton lock would prevent legitimate concurrent worktrees.
Adding a second bind-address field would duplicate the existing process
readiness endpoint and permit contradictory configuration.

Tradeoffs:
Only loopback HTTP readiness probes provide an address devloop can own and
diagnose generically. State-key and remote readiness probes retain their
existing process-exit and timeout errors.

Architectural impact:
Runtime workflow effects now carry startup versus runtime origin. That origin
controls whether a failed first-readiness attempt may apply the configured
restart policy, while later recoverable workflows keep their existing restart
behavior. Runtime failures are written and printed independently of tracing
filters.
Context:
The managed-port collision fix is validated and ready for a patch release.

Decision:
Move the unreleased fix into the 2026-09-01 version section and align Cargo
package metadata with release 0.10.4.

Alternatives considered:
A minor release was unnecessary because the change repairs startup failure
handling without adding a new command or configuration contract.

Tradeoffs:
This release documents only the net collision fix; implementation and test
detail remain in the preceding commit and pull request.

Architectural impact:
No further runtime boundaries change in this commit. It synchronizes the
changelog, package version, release-notes input, and intended v0.10.4 tag.
@pasunboneleve
pasunboneleve merged commit 189022b into main Sep 1, 2026
2 checks passed
@pasunboneleve
pasunboneleve deleted the fix/6z5h-port-collision branch September 1, 2026 06:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant