Skip to content

Add support for container wait conditions #2487

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tejksat
Copy link
Contributor

@tejksat tejksat commented Aug 4, 2025

Expose the condition query parameter (added in Docker Engine API v1.30) on WaitContainerCmd. When the parameter is omitted, we keep the daemon’s default not-running behaviour.

Practical implications

  • create → wait (no condition) → start Calling wait right after create but before start returns immediately with whatever exit-code the daemon reports for a container that has never run (typically 0). In other words, you learn nothing about the future process.

  • create → start → wait (no condition) For short-lived containers started with --rm, the container may be auto-removed before the client manages to issue wait, resulting in a "container not found" error.

  • create → wait(condition=removed) → start Passing the new removed condition eliminates both races: the wait call blocks until the container has exited and been removed, reliably yielding the actual exit code even for --rm containers.

@tejksat tejksat requested a review from a team as a code owner August 4, 2025 20:50
@tejksat tejksat force-pushed the introduce-condition-parameter-to-wait-container-cmd branch from a2becae to 352e602 Compare August 4, 2025 20:55
Expose the `condition` query parameter (added in Docker Engine API v1.30) on `WaitContainerCmd`. When the parameter is omitted, we keep the daemon’s default `not-running` behaviour.

Practical implications
----------------------
* **create → wait (no condition) → start**
  Calling `wait` right after `create` but **before** `start` returns immediately with whatever exit-code the daemon reports for a container that has never run (typically `0`). In other words, you learn nothing about the future process.

* **create → start → wait (no condition)**
  For short-lived containers started with `--rm`, the container may be auto-removed before the client manages to issue `wait`, resulting in a *"container not found"* error.

* **create → wait(condition=removed) → start**
  Passing the new `removed` condition eliminates both races: the wait call blocks until the container has exited *and* been removed, reliably yielding the actual exit code even for `--rm` containers.
@tejksat tejksat force-pushed the introduce-condition-parameter-to-wait-container-cmd branch from 352e602 to 85ec0be Compare August 4, 2025 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy