testcontainers / testcontainers/testcontainers-java

Container restart retried without waiting

Offen
#942 11 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

modules/jdbc resolution/acknowledged type/bug
Vorherrschende Sprache
Java
Sterne
8.7k
Forks
1.9k
Ø Merge
2 T. 17 Std.
Gemergte PRs (30 T.)
9

Beschreibung

Hi, I started using TestContainers today. It simplifies the work a lot! 🎉

However, I'm facing a problem with version 1.9.1 with MySQLContainer.

When I run the tests locally it works like a charm. However, in another computer it is trying to spawn 3 instances of the container without waiting between attempts. This is happening because an exception happened before the wait strategy could be invoked.

The exception in my case is the following:

java.lang.IllegalStateException: copyFileToContainer can only be used with created / running container
	at org.testcontainers.containers.GenericContainer.copyFileToContainer(GenericContainer.java:1075)
	at org.testcontainers.containers.GenericContainer.copyFileToContainer(GenericContainer.java:1067)
	at java.util.HashMap.forEach(HashMap.java:1289)
	at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:262)
	at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:237)
	at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:76)
	at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:235)
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:220)
	at org.testcontainers.containers.GenericContainer.starting(GenericContainer.java:738)
	at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:29)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)

As you can see, it is thrown, from GenericContainer#tryStart, before reaching the invocation of the retry strategy.

It looks like it might be caused by the container not being started yet. So maybe it is taking some milliseconds more in that computer. So maybe executing the wait strategy before the copy operation starts might help.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne in GenericContainer#tryStart und untersuche anhand des Stack Traces den Retry-Pfad rund um copyFileToContainer und die Wait-Strategie. Bestätige das Retry-Verhalten, wenn der Start einen Fehler auslöst, bevor die Wait-Strategie aufgerufen wird; abgeschlossen ist es, wenn Retries nicht länger Container starten, ohne zu warten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
docker, java
Bereich
devops, testing
Issue-Typ
Bug
Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.