Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

DictStore: a multi-chunk external leaf can be read across a concurrent overwrite, mixing two generations

Aperta
#693 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
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
databases

Direzione di ricerca

Inizia con DictStore.getitem, il percorso di lettura dei chunk del livello C e il test esistente test_dict_store_read_during_overwrite; riproduci il caso con più chunk descritto nell'issue. La modifica è completa quando le sovrascritture concorrenti non consentono più a una lettura di combinare chunk di generazioni diverse, tenendo conto del workaround di locking documentato e delle guide interessate.

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

Descrizione

Overwriting an external DictStore leaf while another process reads it can hand that reader an array assembled from two different generations of the value. No error is raised and the data is not corrupt — the array simply never existed as a stored value.

Cause

The handle DictStore.__getitem__ returns holds no file descriptor. The C layer re-opens the leaf by path for every chunk it decompresses, so one arr[:] over an N-chunk leaf is N independent opens. A concurrent __setitem__ on the same key swaps a new leaf into place between two of those opens, and the read takes its low chunks from the old file and its high chunks from the new one.

This is the layer underneath #692. That one was about readers hitting a partial file and failing with RuntimeError: Error while getting the buffer; the fix (build the leaf beside its final name, os.replace() it in) made every file a reader can open complete. Chunks now decompress correctly — but not necessarily all from the same generation.

Reproducer

A 40-chunk leaf, one reader handle, a writer process atomically replacing the file in a loop. Each generation i is np.full(N, i), so any mix is visible as more than one distinct value:

N, CHUNK = 4_000_000, 100_000
blosc2.asarray(np.full(N, 0, dtype=np.int64), chunks=(CHUNK,), urlpath=path, mode="w")
handle = blosc2.open(path, mode="r")
# writer process, in a loop:
#   blosc2.asarray(np.full(N, i, dtype=np.int64), chunks=(CHUNK,), urlpath=tmp, mode="w")
#   os.replace(tmp, path)
data = handle[:]
assert len(np.unique(data)) == 1   # fails

Result on an M4 Pro (macOS, blosc2 4.10.1.dev0):

TORN on read 27: generations [34 35] ... (2 distinct)
reads=249 torn=38 runtime_errors=0

38 of 249 reads straddled a swap. runtime_errors=0 confirms the atomic replace is working; this is a separate failure mode.

Scope
  • Needs a concurrent overwrite of the same key — a write-then-read store never sees it.
  • Single-chunk leaves are immune (one open per read). That is why test_dict_store_read_during_overwrite never caught it: its leaf is 800 bytes.
  • Scales the wrong way: the bigger the leaf, the more opens per read and the wider the window.
Possible fixes
  1. Versioned leaf names (hot.<tick>.b2nd): an overwrite writes a new path, and the reader keeps reading the generation it resolved under the lock. The real fix — MVCC in effect — at the cost of a reclamation story for stale versions.
  2. Hold the store lock across the whole read: __getitem__ could no longer return a lazy handle; callers would need a context manager or a read-into-memory API.

Documented as an accepted race for now (DictStore docstring and the "Sharing Containers Across Processes" guide), with holding_lock() around a copy-out as the workaround.

Lingua principale
Python
Stelle
212
Fork
66
Merge medio
1g 21h
PR unite (30g)
10

Preparare l'ambiente

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 Blosc/python-blosc2

Tutte le issue di Blosc/python-blosc2

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.