Central new-partition zero-progress seed can overwrite another process's committed progress and resend rows

Aperta
  • Qualcosa non va?
#2,786 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à
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript, node.js
Ambito
backend, databases

Direzione di ricerca

Start with hypaware-core/plugins-workspace/central/src/sink.js, especially ensureOpenDatasetPartition and withDatasetRolloutLock, then trace the watermark file operations and upload claim used for progress commits. Reproduce the stated interleaving with the deterministic probe described in the issue. Done means zero-progress seeding cannot overwrite progress committed by another process, and the regression case no longer resends row 1.

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

Descrizione

Found in review of #2785. This is pre-existing: it reproduces on master before that PR (7973e82e) and on the PR head.

When a central sink sees a new partition of an open dataset, ensureOpenDatasetPartition in hypaware-core/plugins-workspace/central/src/sink.js reads the partition's progress and, if none exists, writes zero progress. The read and the write are separate steps, and the only lock around them is in-process (withDatasetRolloutLock). A foreground hyp sync and the daemon run in separate processes, so neither excludes the other.

Interleaving that resends rows:

  1. Process A reads progress for the new partition: absent. A pauses.
  2. Process B reads absent, writes zero, uploads row 1 and commits progress seq 1.
  3. Process A writes zero over B's committed seq 1.
  4. A's upload reloads seq 0 and sends rows 1 and 2, so row 1 goes to central twice.

The #2785 upload claim does not cover this: rollout preparation runs before the claim is taken, so the claimed pass faithfully reloads the stale zero.

Reproduction: a deterministic probe runs two independent sink instances, each with its own per-runtime rollout map, sharing real watermark files, and pauses one instance's progress read. That models the cross-process interleaving without spawning two OS processes. It reads 0 then 0, posts row1, then row1+row2, final seq 2, with the same result at the PR head and at the parent. Whether central stores the resent row twice was not tested.

Expected: seeding zero progress must never overwrite progress another process has committed. Two candidate fixes: write the seed create-only (fail or no-op if a progress file already exists), or run the new-partition seed inside the same cross-process upload claim.

🤖 Generated with Claude Code

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

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.