[Feature]: Inverse of "GenericContainer.waitingFor()" to catch failing startup, avoid long wait

Module

No response

Problem

I have a container that takes quite a while to start up successfully (with somewhat unpredictable time, requiring longish time out for positive signal), but can fail quickly; in both cases there are log lines that are reliable indicators.

But there is no way to check for negative indicators (in my case, log line stating Unable to start server. Exiting...), and as a result failure detection with timeout (failing to find positive signal) takes a very long time, due to necessity of using relatively long timeout for getting success signal.

Solution

It would be great to have an option for short-circuiting this by indicating failure condition(s): this could also be propagated as failure reason to calling code including transparency.

I realize that often testing for negative cases is fool's errand (there may well be countless ways for things to fail); but at least in my case there is one very common failure mode.

Note: it is not necessary to support all the options of waitingFor(): for me ability to match log entries would be sufficient.

Benefit

For use cases like mine there would be much faster runtime for cases where container startup can fail in a detectable way.

Alternatives

I do not TestContainers well enough to know if something like this might already exist (apologies if so; I did try to google for it), or if there is an alternative approach.

Would you like to help contributing this feature?

No

Beginne mit der API GenericContainer.waitingFor() und verfolge, wie das Startup-Ergebnis den aufrufenden Code erreicht. Bestimme den Geltungsbereich einer negativen Log-Match-Bedingung und wie ihr Fehlergrund offengelegt werden sollte; abgeschlossen ist die Aufgabe, wenn eine dokumentierte, getestete API vorhanden ist, die bei dem gemeldeten Startup-Fehler sofort abbricht.