Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#11,719 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
docker, java
Área
testing-qa

Línea de trabajo

Comienza con GenericContainer.start() y stop(), especialmente con la protección de containerId descrita en el issue. Revisa el PR #11702 y el ejemplo concurrente de @Testcontainers y @Container; se considera terminado cuando las llamadas concurrentes a start y stop son seguras, no crean contenedores duplicados ni gestionan incorrectamente la dependencia compartida.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Java
Estrellas
8.7k
Forks
1.9k
Merge medio
17 h 38 min
PR fusionados (30 d)
3

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de testcontainers/testcontainers-java

Todos los issues de testcontainers/testcontainers-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.