Perhaps WaitFor... default timeout should not be waiting indefinitely?

[jetersen]

WaitForHealthy uses Timespan timeout = default which is indefinitely. WaitForPort uses double millisTimeout = double.MaxValue which also feels like indefinitely.

Perhaps it would be better to have a 10 minute default timeout as in CI/CD or Test scenario you could be waiting for a container to never recover. This could turn into a costly endeavor when your paying minutes for build time (GitHub Actions 😉) User can always overwrite the timeout periode if they need more time.

[mariotoffia]

Hmm... or maybe have a setting that you can control e.g. environment variable FLUENTDOCKER_WAITFOR_TIMEOUT that you can set as a DevOps?

[jetersen]

FLUENTDOCKER_WAITFOR_TIMEOUT could be one option, though I think the better option might be to set a reasonable timeout by default and perhaps check if FLUENTDOCKER_WAITFOR_TIMEOUT to override the sane default, so the user can override once instead of everywhere.

[mariotoffia]

That's true! 😊 but what is a sane timeout? - may have different timeouts on their specific workloads and environments.

What I mean by that is that quite a few expect it to run for at least a certain amount of time - changing it now in a non-breaking release number would absolutely break some functionality (I know for certain some inhouse apps would probably break if we set it below 5 - 30 minutes....).

That's why I thought FLUENTDOCKER_WAITFOR_TIMEOUT would be an unintrusive way and do not break backwards compatibility but still, you get your ability to provide the timeout externally.

I'm open to suggestions.

Cheers, Mario 😊