Skip to content

Fail fast and clean up when Playground bind port is occupied #1824

Description

@chubes4

Problem

A recipe-run selected a loopback port already held by an existing SSH listener. Playground emitted listen EADDRINUSE, but the run remained blocked in input.materialize until the outer 20-minute timeout sent SIGTERM. The managed disposable MySQL container remained running and required operator cleanup.

Evidence

  • Bind error: listen EADDRINUSE: address already in use 127.0.0.1:63055.
  • The pre-existing owner was an SSH listener with PPID 1, started roughly 14 hours before the recipe run.
  • Artifact pointer remained at lastCommand: input.materialize and recorded interruption by SIGTERM only when the outer timeout expired.
  • The managed wp-codebox-mysql-* container remained up after termination.

Expected

  1. Dynamic Playground port allocation excludes ports that cannot be bound, or retries allocation on EADDRINUSE.
  2. Runtime startup/materialization propagates the bind failure immediately instead of hanging.
  3. Managed runtime services are torn down on this terminal startup failure and SIGTERM path.

Reproduction

  1. Hold a local TCP listener on a candidate Playground bind port.
  2. Force or stub dynamic allocation to return that occupied port.
  3. Run a recipe with a managed service and an input mount requiring materialization.
  4. Assert the run fails promptly with structured bind diagnostics and the managed service lifecycle reaches released/teardown: completed.

Discovered while validating #1821 against a real mounted WPCOM PHPUnit recipe.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions