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

PostgresProvider.connectWithSchema races on concurrent first-time startup and fails with pg_namespace_nspname_index duplicate key

Abierto
  • ¿Algo no está bien?
#7 0 comentarios 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
postgresql, rust
Área
backend, database

Línea de trabajo

Comienza en el punto de entrada del proveedor PostgreSQL de duroxide-pg, PostgresProvider.connectWithSchema, y sigue el flujo de creación e inicialización de los esquemas. Reproduce el problema eliminando los esquemas de duroxide e iniciando cuatro workers de forma concurrente contra la misma base de datos. Se considera terminado cuando los primeros llamadores concurrentes pueden inicializar de forma segura o tratar la condición de carrera de esquemas duplicados como un éxito, mientras que el inicio secuencial y los inicios posteriores siguen funcionando.

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

Descripción

Title: PostgresProvider.connectWithSchema races on concurrent first-time startup and fails with pg_namespace_nspname_index duplicate key

Summary

Concurrent first-time startup against PostgreSQL can fail inside the duroxide-pg provider when multiple workers call PostgresProvider.connectWithSchema(...) at the same time. The losing workers fail with:

duplicate key value violates unique constraint "pg_namespace_nspname_index"

This happens during schema creation/initialization in the PostgreSQL provider. It leaves callers thinking worker startup hung or partially failed.

Environment

  • Host: macOS
  • Client app: PilotSwarm local TUI embedding 4 workers in one process
  • Database: local PostgreSQL
  • Provider path: PostgresProvider.connectWithSchema(...)
  • Observed on first startup immediately after dropping the duroxide-related schemas

Repro

  1. Drop the duroxide/application schemas so the next run starts from a clean database.
  2. Start 4 workers concurrently against the same PostgreSQL database and same duroxide schema.
  3. Each worker calls PostgresProvider.connectWithSchema(store, schema) during startup.

Pseudo-code:

await Promise.all([
  worker0.start(),
  worker1.start(),
  worker2.start(),
  worker3.start(),
]);

Where each worker.start() calls into:

await PostgresProvider.connectWithSchema(store, duroxideSchema)

Actual result

Usually 1 worker succeeds and the others fail immediately with an error like:

Failed to connect to PostgreSQL: error returned from database:
duplicate key value violates unique constraint "pg_namespace_nspname_index"

From our startup trace:

worker local-rt-3 start failed ms=33 err=Failed to connect to PostgreSQL: error returned from database: duplicate key value violates unique constraint "pg_namespace_nspname_index"
worker local-rt-0 start failed ms=35 err=Failed to connect to PostgreSQL: error returned from database: duplicate key value violates unique constraint "pg_namespace_nspname_index"
worker local-rt-1 start failed ms=34 err=Failed to connect to PostgreSQL: error returned from database: duplicate key value violates unique constraint "pg_namespace_nspname_index"

Meanwhile one worker succeeds and continues normally.

Expected result

Concurrent callers should be able to race safely on first-time schema initialization. The PostgreSQL provider should either:

  • make schema creation idempotent under concurrency, or
  • catch and treat the duplicate-schema path as success, then continue initialization.

Impact

This showed up as a blank/hung first-run local TUI startup in PilotSwarm because multiple embedded workers were started concurrently. Reverting to sequential worker startup works around the problem, but the bug appears to be in the duroxide PostgreSQL provider itself rather than in the application.

Notes

  • This is specifically in the duroxide-pg / PostgreSQL provider path, not an application-level session-state bug.
  • Serial worker startup avoids the issue.
  • Once the schema already exists, subsequent startups generally succeed.
Lenguaje dominante
Rust
Estrellas
226
Forks
62
Merge medio
20 h 46 min
PR fusionados (30 d)
6

Preparar el entorno

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 microsoft/duroxide

Todos los issues de microsoft/duroxide

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.