Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: GenericContainer.start() and stop() are not thread-safe

Aperta
  • Qualcosa non va?
#11,719 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@remal ci sta già lavorando.

Dal 13/4/2026.

  • #11702 di @remal — aperta
  • #12063 di @adityasonani — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
docker, java
Ambito
testing-qa

Direzione di ricerca

Inizia da GenericContainer.start() e stop(), in particolare dal controllo di containerId descritto nell’issue. Esamina la PR #11702 e l’esempio concorrente con @Testcontainers e @Container; il lavoro è completato quando le chiamate concorrenti a start e stop sono sicure, non creano container duplicati e non gestiscono in modo errato la dipendenza condivisa.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type/bug
Module

Core

Testcontainers version

2.0.4

Using the latest Testcontainers version?

Yes

What happened?

GenericContainer.start() guards against double-start with if (containerId != null) return, but start() is not synchronized. When two threads call start() on the same container concurrently, both can pass the guard before either sets containerId, creating two Docker containers for one logical dependency.

This can happen when @Testcontainers is used and the container is also started from another context. For example, custom test infrastructure that handles @Container annotations alongside the JUnit extension:

@Testcontainers
class MyTest {

    // Custom infrastructure starts this container during context setup.
    // The @Testcontainers extension also starts it via Startables.deepStart().
    // Both run concurrently - the second start() should be a no-op, but without
    // synchronization both threads pass the containerId == null check.
    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:16");
}

The workaround is to not annotate dependencies with @Container when custom infrastructure already handles them, but this is not obvious to developers and error-prone.

I can't provide the exact scenario because we faced this in a closed-source project. The example above illustrates the general pattern.

Additional Information

I submitted a PR with a fix: #11702

Lingua principale
Java
Stelle
8.7k
Fork
1.9k
Merge medio
17h 38m
PR unite (30g)
3

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di testcontainers/testcontainers-java

Tutte le issue di testcontainers/testcontainers-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.