Skip to content

Make doctor mock-server port run-scoped to preserve parallelism #162

Description

@ebursztein

Summary

The Linux full just test run exposed a real fixed-port race in capsem doctor: doctor starts capsem-mock-server on 127.0.0.1:3713, while the Python test harness can run other mock-server-backed tests in parallel. When another process owns that fixed address, doctor fails with Address already in use.

The 1.5 release fix serializes that fixed-port resource with the same address-scoped lock used by the Python harness, which removes the flake without changing the guest/network contract. That is correct for the current fixed-port design, but it still means multiple doctor runs using the same address cannot run concurrently.

Follow-up

Make the doctor mock-server address run-scoped/injectable so parallel doctor invocations can use different ports and therefore different address-scoped locks.

Acceptance criteria

  • capsem doctor can allocate or accept a per-run mock-server port instead of always requiring 127.0.0.1:3713.
  • The guest iptables redirect and any doctor/network assertions use the selected address consistently.
  • The lock remains keyed by address so identical addresses serialize, while different ports can run concurrently.
  • Add a regression test that starts/holds two distinct mock-server address locks and proves they do not block each other.
  • Add/adjust an e2e doctor test that proves the selected port works through the guest redirect path.
  • Keep the current fixed-port behavior available where release/diagnostic contracts still need it.

Evidence from current work

  • Failure observed in full Linux just test: Error: bind HTTP, Address already in use (os error 98) on 127.0.0.1:3713.
  • Targeted doctor e2e passed after lock fix.
  • Forced lock-contention check passed after lock fix by waiting instead of racing the bind.
  • Full parallel Linux run continued with four pytest workers interleaving unrelated tests, so the current lock is scoped to the fixed mock-server resource rather than the entire suite.

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