Publish: lock concurrent publishes and catch edits after staging
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- Mezza giornata
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- sqlite, typescript
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- HTML
- Stelle
- 0
- Fork
- 0
- Merge medio
- 1m
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di mrgnw/cfcms
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
G-nn-r/lg_heatpump#52 ·
-
area: core bug priority: high
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
griffinwork40/agent-afk#4872 ·
I maintainer di solito rispondono entro 1 giorno
-
fleet size/m
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
sipyourdrink-ltd/bernstein#7517 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
BUG-MERGE-TO-HDR-RESULT-NAMEForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
storytold/photocraft#14025 ·
I maintainer di solito rispondono entro 1 giorno