feat: added CommandStrategy with SuccessfulCommand enum by sutt0n · Pull Request #782 · testcontainers/testcontainers-rs

sutt0n · 2025-03-30T19:39:28Z

Potentially resolves #702

This introduces a new wait strategy, CommandStrategy. The goal here is to wait for a successful command (exit code 0) prior to marking a container as ready. This polls the container state to ensure it's running first, and then executes the given command. Once the command has an exit code of 0, then the strategy has completed.

There are options to fail fast, as well as customize the exit code, just to expose flexibility for the strategy.

Open to changes / updates, if required -- this language is not my day-to-day.

netlify · 2025-03-30T19:39:49Z

✅ Deploy Preview for testcontainers-rust ready!

Name	Link
🔨 Latest commit	`9e1c3db`
🔍 Latest deploy log	https://app.netlify.com/projects/testcontainers-rust/deploys/68730f5ace06fd0008447740
😎 Deploy Preview	https://deploy-preview-782--testcontainers-rust.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

DDtKey

Thank you for the contribution!

I've left a comment, please take a look

DDtKey · 2025-03-30T23:02:27Z

testcontainers/src/core/wait/command_strategy.rs

Can't this be achieved with exec_after_start with ExitCode wait condition (it waits for exit)? Additionally, this way allows to rely on a container's state

Or we could consider extending existing wait conditions if it's not enough

But generally speaking, at first glance it looks like duplicate functionality

Now that you mention it and after a second glance, it feels like duplicate functionality. This was probably an oversight on my end by lack of context.

I can test what you've provided and report back findings - that may aid in either resolving or progressing a solution for this issue.

After investigating, the difference here is that this adds a "command strategy" similar to "shell strategy" (with an emphasis on SuccessfulCommand) here:

https://node.testcontainers.org/features/wait-strategies/#shell-command

To be more orthogonal / consistent with the Node test container, what do you think about this just being ShellStrategy instead? It has the same functionality, if I'm not mistaken:

https://github.com/testcontainers/testcontainers-node/blob/main/packages/testcontainers/src/wait-strategies/shell-wait-strategy.ts#L6

Whereas WaitFor is similar to: https://github.com/testcontainers/testcontainers-node/blob/b92f6695de10863c6ea90d169f999b79406d162e/packages/testcontainers/src/wait-strategies/wait.ts#L40

Thoughts?

We don't have to be fully consistent with other languages. You can find a lot of differences between Go, Java and Node, for example (but we try to be aligned when possible)

Also, we should compare exec_after_start with strategies here, not the WaitFor itself.

However we can consider such strategy for sure, more like "alias" or "short/easier way".
But we need to avoid maintaining of duplicative logic/code. Let me explain:

What are we introducing here that is missing in exec_after_start?
If it's about "easier way" - we need to find a way to compose it more correctly
But if there is a difference in functionality - then it should be very clear to users why to use one over the other

Let's consider the current implementation to understand if it's clear enough

.with_wait_for(WaitFor::SuccessfulCommand( CommandStrategy::command( ExecCommand::new(["pg_isready"]).with_cmd_ready_condition(CmdWaitFor::exit_code(0)), ), ))

What confuses me a little bit here:

with_cmd_ready_condition(CmdWaitFor::exit_code(0) - expects exit-code = 0

SuccessfulCommand - also expects exit-code = 0 (implicitly)

What if I'd change with_cmd_ready_condition to expect non-zero code or something else?

Do I really need to specify this two times as a user?

Perhaps, instead I'd suggest to support something like fail_fast/retry for ExecCommand
And add very simple strategy, like Command(ExecCommand)

So it will look like:

.with_wait_for( WaitFor::command( ExecCommand::new(["pg_isready"]).with_cmd_ready_condition(CmdWaitFor::exit_code(0)) ) )

Apologies for the delay, been a busy week here with the weather we've been getting in Arkansas. 😅

~~I've pushed an update that I believe is something that aligns... I was hesitant on the CmdWaitFor::exit_code(0) in WaitFor::command(), but added it anyway.~~

~~...however, now that I think about it, we may want to not force that specific exit code, but allow users to specify one on their own. Thoughts?~~

Nevermind. I've allowed this to be more general than specific.

testcontainers/src/core/wait/mod.rs

DDtKey · 2025-04-06T02:25:12Z

testcontainers/src/core/wait/command_strategy.rs

+#[derive(Debug, Clone)]
+pub struct CommandStrategy {
+    expected_code: i64,
+    poll_interval: Duration,
+    command: ExecCommand,
+    fail_fast: bool,
+}


It seems unchanged - we still have expected_code here which may contradict to ExecCommand wait conditions

The idea was to change how it's organized and implemented
#782 (comment)

Apologies for this overlook -- updated!

@DDtKey Is there anything else you'd like fixed on this PR?

@DDtKey Wanting to follow up here, is there anything else you'd like to see addressed on this PR that I may have missed?

Hi @sutt0n, sorry for the delay

I'll take a fresh look soon and drop a message if I have any more questions.

@DDtKey no worries and sounds great! let me know if there are more changes required, please and ty.

@DDtKey Hey just wanting to touch base and ensure that this PR doesn't get too stale.

Sorry, @sutt0n did you check my comment below #782 (comment)? Could you check if it works for you or we still need something else

sutt0n · 2025-04-06T13:07:43Z

Force pushed to fix the commit message... hard to write Rust while holding a sleeping baby. 😅

DDtKey · 2025-07-16T16:17:56Z

Sorry again for the long delay.

@sutt0n, do you think this solution would address your use case as well?
I find it more natural and aligned with the Docker interface, while still offering nearly the same functionality — the ability to wait for an arbitrary command to succeed during startup.

feat: added CommandStrategy with SuccessfulCommand enum

edf5f14

docs: added wait for variant to wait_strategies document

7d449aa

DDtKey reviewed Mar 30, 2025

View reviewed changes

DDtKey reviewed Apr 1, 2025

View reviewed changes

testcontainers/src/core/wait/mod.rs Outdated Show resolved Hide resolved

sutt0n added 2 commits April 5, 2025 17:23

refactor(wait-for): utilize WaitFor::command(ExecCommand)

7475502

refactor: allow WaitFor::command() to be more general than specific

86fa407

sutt0n requested a review from DDtKey April 5, 2025 22:28

docs: update

8a34464

DDtKey reviewed Apr 6, 2025

View reviewed changes

sutt0n requested a review from DDtKey April 6, 2025 11:30

refactor(command-strategy): use exit code from ExecCommand

cee5d7e

sutt0n force-pushed the feat/command-strategy branch from e9caf57 to cee5d7e Compare April 6, 2025 13:06

Merge branch 'main' into feat/command-strategy

9e1c3db

DDtKey mentioned this pull request Jul 15, 2025

[feature request] Allow overriding the container health check #814

Closed

sutt0n closed this Sep 16, 2025

sutt0n deleted the feat/command-strategy branch September 16, 2025 03:07

DDtKey mentioned this pull request Oct 22, 2025

fix: Support Postgres ready_conditions for already mounted volumes testcontainers/testcontainers-rs-modules-community#416

Open

Comments

Conversation

sutt0n commented Mar 30, 2025

Uh oh!

netlify bot commented Mar 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for testcontainers-rust ready!

Uh oh!

DDtKey left a comment

Choose a reason for hiding this comment

Uh oh!

DDtKey Mar 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sutt0n Mar 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sutt0n Apr 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DDtKey Apr 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DDtKey Apr 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sutt0n Apr 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

DDtKey Apr 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sutt0n Apr 6, 2025

Choose a reason for hiding this comment

Uh oh!

sutt0n Apr 21, 2025

Choose a reason for hiding this comment

Uh oh!

sutt0n May 28, 2025

Choose a reason for hiding this comment

Uh oh!

DDtKey May 28, 2025

Choose a reason for hiding this comment

Uh oh!

sutt0n Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sutt0n Jul 13, 2025

Choose a reason for hiding this comment

Uh oh!

DDtKey Sep 15, 2025

Choose a reason for hiding this comment

Uh oh!

sutt0n commented Apr 6, 2025

Uh oh!

DDtKey commented Jul 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

netlify bot commented Mar 30, 2025 •

edited

Loading

DDtKey Mar 30, 2025 •

edited

Loading

sutt0n Mar 31, 2025 •

edited

Loading

sutt0n Apr 1, 2025 •

edited

Loading

DDtKey Apr 1, 2025 •

edited

Loading

DDtKey Apr 1, 2025 •

edited

Loading

sutt0n Apr 5, 2025 •

edited

Loading

DDtKey Apr 6, 2025 •

edited

Loading

sutt0n Jun 23, 2025 •

edited

Loading