perf: search index rebuild is not atomic and drops tables on concurrent requests
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- typescript
Línea de trabajo
Empieza en src/server/api/search.ts leyendo buildIndex() y ensureIndex(), y sigue después indexedVersions e indexPromise. Sustituye el flujo de eliminar y volver a crear por el intercambio de tablas temporales, elimina la dependencia de /tmp/chronicle-search-ready y asegúrate de que las compilaciones concurrentes esperen a que termine una única compilación. Se considera terminado cuando las solicitudes de búsqueda concurrentes ya no fallan durante la construcción del índice.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
src/server/api/search.ts drops and recreates FTS tables in buildIndex() on each version init. If two requests hit the search endpoint simultaneously during index build, the second request can fail because the tables were just dropped.
The lock file mechanism (/tmp/chronicle-search-ready) is also unreliable across processes and deployments since temp files get cleaned.
Suggested Fix
- Build the new index in temporary tables, then atomically swap (rename) them
- Replace the lock file with an in-memory ready flag (already have
indexedVersionsset — lean on that) - Add a mutex/promise guard so concurrent
ensureIndex()calls wait for the first build to complete (partially done viaindexPromisebut the drop/recreate pattern still races)
- Lenguaje dominante
- TypeScript
- Estrellas
- 2
- Forks
- 1
- Merge medio
- 12 min
- PR fusionados (30 d)
- 1
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de raystack/chronicle
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 65/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Todos los issues de raystack/chronicle
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
apache/rocketmq-dashboard#6610 ·
Los mantenedores suelen responder en 3 días
-
nextjs-tracking
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
cloudflare/vinext#3920 ·
Los mantenedores suelen responder en 1 día
-
Team:Dashboards
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
elastic/kibana#297299 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
analytics beginner friendly community contributions-welcome good first issue hacktoberfest help wanted up-for-grabs
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
affected/v17 affected/v18 area/frontend type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
umbraco/Umbraco-CMS#24186 ·
Los mantenedores suelen responder en 2 días