RFC: Ingester ack in Postgres; `failed/` only for bad submissions
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 45/100
Direzione di ricerca
Inizia tracciando ingest_submissions_parallel e monitor_submissions, quindi esamina transaction.atomic, assign_lab_ids, il counter_lock esistente e la gestione di writer.exitcode. Definisci lo schema e la concessione dei ruoli prima di implementare le scritture atomiche dei fatti e delle righe applicate, i riconoscimenti dello spool, l’interruzione dei tentativi e il comportamento di quarantena; il lavoro è completato quando i risultati indicati sono validi per ogni caso di errore.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The Problem
Valid submissions passed schema and log-excerpt upload. Database insertion then failed. The ingester moved the whole batch to failed/ — the directory for invalid data. That directory was cleaned up, so good data was treated as poison.
Rules
failed/ — invalid JSON and errors of the submission itself. Cases where retry cannot help.
DB insert / flush failure — files are not moved and nothing is acked. The spool is the retry queue; fact inserts are upserts, so a later attempt is safe.
Applied — a row in ingested_submissions, inserted in the same transaction.atomic() as the facts (assign_lab_ids moves into that transaction so "applied" is one boundary). The file is deleted only after that commit.
hash text PK -- sha256 of raw file bytes
file_name text
_timestamp timestamptz -- `field_timestamp`
Scan deletes any file whose hash is already present, which covers a crash between commit and unlink.
Flush writes all entity buffers in one commit and acks exactly the hashes in it, so no file is finalized while its rows are still buffered.
Stop on stuck retry — one shared multiprocessing.Value("d") holds the last time a submission reached a terminal state, updated under the existing counter_lock on an apply commit and on a quarantine. Checked only while work is pending, in the poll loop of ingest_submissions_parallel and the monitor loop of monitor_submissions. If nothing has reached a terminal state for T, the process exits non-zero; files stay in the spool. Existing writer.exitcode handling stays for crashes; the timestamp covers hangs and persistent errors, which never raise.
If a file is kept on spool dir after for a long enough grace period of time, we can abort and raise an error on the ingester.
New table: GRANT the ingester role before shipping the writer.
| Error we had | Outcome |
|---|---|
| Insert exception | Files stay, nothing in failed/, retried; process exits after T |
| Invalid JSON / bad submission | That file → failed/ |
| Successful commit | Ack row, then file deleted |
- Lingua principale
- Python
- Stelle
- 9
- Fork
- 31
- Merge medio
- 5g 22h
- PR unite (30g)
- 19
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun 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 kernelci/dashboard
-
4xx and 5xx by endpointForse già presa @alanpeixinho l’ha presa 4 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
[Local dev environment] PRIVACY.md missing in dashboard containerForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 2 giorni
-
[AB Comparison] Add labels to Previous commit and Branch head buttonsForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di kernelci/dashboard
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
FuRongJun-1999/dsh-memory#65 ·
I maintainer di solito rispondono entro 1 giorno
-
ci needs-ac
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
Ikalus1988/MisakaNet#2930 ·
I maintainer di solito rispondono entro 1 giorno
-
`FakeBackendV2.run` fails with `NoiseError` on circuits with delays on qubits where T2 > 2·T1Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Qiskit/qiskit-aer#2466 ·
-
area/cli
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100