Skip to content

bug(remote): join enable work and retain failed owners during disposal #941

Description

@Juliusolsson05

Expected behavior

Remote disposal closes new enable admission, joins already-admitted enable/disable work and retains the exact server until its stop completes. A rejected stop must remain retryable through the owner that performed the original start.

Confirmed source and regression

At application base 115e26fc9c67316a3b0b1b4318f47f7a2bea3606, RemoteController.dispose() calls teardown outside the enable/disable FIFO. A pending enable can publish a server after disposal returns. teardownLive() also clears this.server before awaiting stop; a rejection leaves a later retry with no server to stop.

Source.

Discovered during #919's composition audit. Implemented in branch fix/quit-service-lifecycle, commit e9b88bf5: terminal enable admission, disposal in the same FIFO, no late live-URL publication, and retained server ownership on rejection. Two added regressions exercise the real controller/server stack with controlled transport start/stop promises. The complete nine-case remote system lane passed. The tests prove ownership and ordering at the transport contract; they do not claim an observed native tunnel-process exit beyond that contract.

Acceptance: delayed start during disposal cannot leave an enabled controller; repeated disposal joins one promise; a failed stop retries the same transport and does not construct a replacement. The forthcoming quit-safety PR may close this specific issue, while broader B02/#919 remains open.

Refs #919 and #918. No live user remote server was stopped.

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