Publish: lock concurrent publishes and catch edits after staging
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- sqlite, typescript
Línea de trabajo
Start with the publish path behind POST /api/publish and the staging code that records a post's state in SQLite, then read src/lib/server/db.check.ts to see how the existing checks are written. Add an in-process lock plus a lock file in the blog checkout, returning 409 with a reason on a second publish, and record the staged revision hash so edits after staging are flagged. Done when two simultaneous publish calls yield one success and one 409, a stale lock file is cleared, and the edited-after-staging check passes in db.check.ts.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Context
Two concurrent publishes race on the blog checkout: both render .svx files, build, commit and push. Separately, staging is per post rather than per revision, so an edit made after staging ships on the next publish without being restaged.
Scope
- An in-process publish lock (plus a lock file in the blog checkout so a second server process also respects it). A second publish returns 409 with the reason.
- Record the staged revision hash when a post is staged; at publish time, a post whose head moved since staging is listed as "edited after staging" and is not published until restaged.
Acceptance criteria
- Two simultaneous
POST /api/publishcalls: one succeeds, one gets 409; the checkout is not corrupted. - A stale lock file from a crashed process is detected and cleared.
- A check covers the edited-after-staging case in
src/lib/server/db.check.ts.
Estimate: about 4 hours.
- Lenguaje dominante
- HTML
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 1 min
- PR fusionados (30 d)
- 2
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la 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 mrgnw/cfcms
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Todos los issues de mrgnw/cfcms
Issues similares
-
changelog investigate
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
ramnes/notion-sdk-py#454 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
anthropics/claude-agent-sdk-python#1509 ·
Los mantenedores suelen responder en 2 días
-
from-review-extraction priority: medium python severity:suggested
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
LearningCircuit/local-deep-research#8665 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
external feature request openai
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
langchain-ai/langchain#41853 ·
Los mantenedores suelen responder en 1 día