Corrupt cleanup journal blocks a partition's compaction and snapshot expiry, not only reclamation

Aperta
  • Qualcosa non va?
#2,022 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
backend, databases

Direzione di ricerca

Read src/core/cache/maintenance.js at lines 442 and 660, then the cited design decision in llp/0417-session-purge-across-storage.spec.md lines 233–235 and the referenced LLP 0220 partition-walk behavior. First decide through a new or superseding LLP whether maintenance should continue after an unreadable journal or expose a health signal. Done means implementing that decision and adding a corrupt-journal regression test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Source: #2017 at 6bd3752d4a7e0f3fa70881e5f5e6a8c42aff5854
Location: src/core/cache/maintenance.js:442 (and :660)
Severity: medium

Evidence

maintainGeneration calls readCacheCleanup un-caught at its top (maintenance.js:442), ahead of the compaction and snapshot-expiry work, so a journal that is present but unparseable fails that partition's whole maintenance tick for as long as it stays corrupt; ongoing appends then accumulate snapshots and superseded files in that partition until a later purge of the same partition rebuilds the journal. The blast radius is one partition: the catch at maintenance.js:304 (@ref LLP 0220#walk-survives-a-partition) marks the partition failed and lets the walk continue, and walkForRetired independently catches its own read (maintenance.js:2672).

Why deferral is safe

At this head the behavior is documented design, not a spec-code contradiction: the sentence this PR corrected (llp/0417-session-purge-across-storage.spec.md:233-235) now states that an invalid journal blocks that partition's maintenance, compaction and snapshot expiry included. Changing it, catching the read and proceeding with compaction while refusing only reclamation, is a revisit of a recorded fail-closed decision and needs an LLP, not a code patch. The trigger is rare (journals are written by atomicWriteJson with fsync, tmp plus rename, so a torn journal needs a hand edit or unusual filesystem behavior), the failure is isolated per partition and surfaced as a failed partition report, and a purge of that partition self-heals it.

Acceptance condition

A design decision (new LLP extending or superseding the relevant part of LLP 0417) on whether maintainGeneration should survive an unreadable journal, blocking only reclamation, or whether the blocked-partition state should instead be surfaced as a health signal; then implement per that decision with a corrupt-journal regression test.

Review preference; backlog only. A human may explicitly delegate it with neutral:fix.

Lingua principale
JavaScript
Stelle
11
Fork
0
Merge medio
2h 49m
PR unite (30g)
297

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hyparam/hypaware

Tutte le issue di hyparam/hypaware

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.