Skip to content

feat!: support waiting from both standard streams - #695

Draft
DDtKey wants to merge 1 commit into
mainfrom
feat/support-waiting-on-both-std-streams
Draft

feat!: support waiting from both standard streams#695
DDtKey wants to merge 1 commit into
mainfrom
feat/support-waiting-on-both-std-streams

Conversation

@DDtKey

@DDtKey DDtKey commented Jul 7, 2024

Copy link
Copy Markdown
Contributor

Might be useful to avoid duplication in some cases

@netlify

netlify Bot commented Jul 7, 2024

Copy link
Copy Markdown

Deploy Preview for testcontainers-rust ready!

Name Link
🔨 Latest commit 7305971
🔍 Latest deploy log https://app.netlify.com/sites/testcontainers-rust/deploys/668acd4896539900089b90c3
😎 Deploy Preview https://deploy-preview-695--testcontainers-rust.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

@DDtKey
DDtKey marked this pull request as ready for review July 8, 2024 14:12
@DDtKey
DDtKey marked this pull request as draft July 8, 2024 14:13
@ns-sjorgedeaguiar

Copy link
Copy Markdown
Contributor

@DDtKey on a related note, am I right that it's not possible to wait for the command to complete? I see that we can wait for messages to be present in stderr/stdout, or for a specific exit code, but there doesn't seem to be a away to wait until the command finishes regardless of the outcome. There's the timeout option but it sleeps for the whole duration, not circuit breaking when the command is finished.

In my case I wrote a wrapper to execute a SQL statement, and wanted to print whatever error occurred when there was some. The exit code or expected message depended on what the caller was doing (e.g. inserting, deleting, etc) and the exit code could be anything. My workaround was to keep polling until an exit code was available.

@DDtKey

DDtKey commented Aug 15, 2024

Copy link
Copy Markdown
Contributor Author

Hi @ns-sjorgedeaguiar
Yes, that's correct. however I think more appropriate place for the discussion is #702

Where you also can find a workaround. But it's something we can support for sure

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.

2 participants