[FEATURE] verify declared ports from the setup wizard, on every backend #1

Merged
dunemask merged 1 commit from ep/Oct31-2026/PortableVolumes into main 2026-11-02 22:01:32 +00:00
Owner

A project's ports are now proven before the wizard will continue. The operator
declares a pool on the Networking step, the runner publishes those numbers at its
own responder for the length of one batch, dials each one for a nonce, releases
them, and records a reading per port. Continue stays shut until every entry comes
back verified.

Nothing is published between runs. The responder is an in-pod container port
(8097, chart default) and the publish is created immediately before a batch's
dials and deleted in a finally — on the normal path, on a throw, on a cancelled
run and on an expired deadline. An unconditional startup sweep clears anything a
killed process left behind, because shutdown() exits synchronously on SIGTERM
and a run's finally never gets to run.

Backends: kubernetes publishes a temporary NodePort Service whose selector and
numeric targetPort are read off the agent's own Pod; compose and swarm publish
through the engine and the routing mesh; podman shares docker's code path with
the binary as a parameter. A backend that cannot publish answers unsupported
and every leg stays unknown — no tick, no failure, no streak.

Absence is never a measurement. A port that could not be tested takes one of
twelve named reasons and writes nothing, so it can neither pass nor fail. A dial
whose publish had nothing confirmed behind it is publish-unbacked rather than a
failure: a readiness blip once wrote eleven false failures and armed four 24-hour
deploy refusals. An answered is never demoted — a reply carrying the run's
nonce is its own proof the path was up.

Readings persist to the state PVC with their original instants, so a pod restart
no longer resets every streak and the 24-hour deploy refusal can actually fire.

Proven on k3d, docker compose and docker swarm: 2,765 TCP and 2,765 UDP ports in
eleven batches, small ranges on all three engines, the deadline truncating
honestly, and a real project binding a port the check had just released.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

A project's ports are now proven before the wizard will continue. The operator declares a pool on the Networking step, the runner publishes those numbers at its own responder for the length of one batch, dials each one for a nonce, releases them, and records a reading per port. Continue stays shut until every entry comes back verified. Nothing is published between runs. The responder is an in-pod container port (8097, chart default) and the publish is created immediately before a batch's dials and deleted in a `finally` — on the normal path, on a throw, on a cancelled run and on an expired deadline. An unconditional startup sweep clears anything a killed process left behind, because `shutdown()` exits synchronously on SIGTERM and a run's `finally` never gets to run. Backends: kubernetes publishes a temporary NodePort Service whose selector and numeric targetPort are read off the agent's own Pod; compose and swarm publish through the engine and the routing mesh; podman shares docker's code path with the binary as a parameter. A backend that cannot publish answers `unsupported` and every leg stays unknown — no tick, no failure, no streak. Absence is never a measurement. A port that could not be tested takes one of twelve named reasons and writes nothing, so it can neither pass nor fail. A dial whose publish had nothing confirmed behind it is `publish-unbacked` rather than a failure: a readiness blip once wrote eleven false failures and armed four 24-hour deploy refusals. An `answered` is never demoted — a reply carrying the run's nonce is its own proof the path was up. Readings persist to the state PVC with their original instants, so a pod restart no longer resets every streak and the 24-hour deploy refusal can actually fire. Proven on k3d, docker compose and docker swarm: 2,765 TCP and 2,765 UDP ports in eleven batches, small ranges on all three engines, the deadline truncating honestly, and a real project binding a port the check had just released. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
[FEATURE] verify declared ports from the setup wizard, on every backend
All checks were successful
Build Image / build-image (pull_request) Successful in 1m1s
0ad4924fac
A project's ports are now proven before the wizard will continue. The operator
declares a pool on the Networking step, the runner publishes those numbers at its
own responder for the length of one batch, dials each one for a nonce, releases
them, and records a reading per port. Continue stays shut until every entry comes
back verified.

Nothing is published between runs. The responder is an in-pod container port
(8097, chart default) and the publish is created immediately before a batch's
dials and deleted in a `finally` — on the normal path, on a throw, on a cancelled
run and on an expired deadline. An unconditional startup sweep clears anything a
killed process left behind, because `shutdown()` exits synchronously on SIGTERM
and a run's `finally` never gets to run.

Backends: kubernetes publishes a temporary NodePort Service whose selector and
numeric targetPort are read off the agent's own Pod; compose and swarm publish
through the engine and the routing mesh; podman shares docker's code path with
the binary as a parameter. A backend that cannot publish answers `unsupported`
and every leg stays unknown — no tick, no failure, no streak.

Absence is never a measurement. A port that could not be tested takes one of
twelve named reasons and writes nothing, so it can neither pass nor fail. A dial
whose publish had nothing confirmed behind it is `publish-unbacked` rather than a
failure: a readiness blip once wrote eleven false failures and armed four 24-hour
deploy refusals. An `answered` is never demoted — a reply carrying the run's
nonce is its own proof the path was up.

Readings persist to the state PVC with their original instants, so a pod restart
no longer resets every streak and the 24-hour deploy refusal can actually fire.

Proven on k3d, docker compose and docker swarm: 2,765 TCP and 2,765 UDP ports in
eleven batches, small ranges on all three engines, the deadline truncating
honestly, and a real project binding a port the check had just released.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dunemask deleted branch ep/Oct31-2026/PortableVolumes 2026-11-02 22:01:43 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dunemask/dys!1
No description provided.