Skip to content

rig_https_local / rig_https_bad_finished start the listener before taking the DeviceLock, so a queued run's ACCEPT_TIMEOUT expires #246

Description

@JC-000

Seen during the 2026-09-24 pre-merge hardware runs. A rig_https_local run failed as a fixture problem: it spent 39 min queued for the U64E, and the listener's accept timed out first.

Mechanism. Both rigs start their TLS listener with a wall-clock ACCEPT_TIMEOUT (default 600 s × the turbo scale) before they acquire the DeviceLock. The lock is designed to queue behind a live holder for as long as it takes, so any queue longer than the accept budget fails the run before the C64 ever connects. It looks like a network or rig failure rather than a queue delay.

Workaround used: `ACCEPT_TIMEOUT=10800`.

Fix: take the DeviceLock (and run prepare_device/preflight) first, then start the listener, or start the accept clock only once the lock is held. Pin it with a hardware-free test that fakes a slow acquire.

🤖 Generated with Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions