"stop on error" CLI flag
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
Direzione di ricerca
Start by tracing how the super CLI parses flags and how query errors reach the output writer; the issue does not name specific files or tests. Compare those paths with the query-level early-exit proposal in #5298 and error-propagation concern in #6696. Done means a documented -stoponerror behavior can stop the process on the chosen error conditions and return a non-zero exit code.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
For debug purposes or certain production scenarios, users may benefit from a -stoponerror CLI flag that would cause a running query to exit entirely (and probably cause super to return a non-zero exit code) in reaction to error values that appear during the running of a query.
Details
At the time this issue is being opened, super is at commit 508a543.
An advisor has recently bumped into a desire for this functionality while prototyping his "paged API" use case, though many of us on the project team have envisioned the benefits of this as well.
SuperSQL has its functions like is_error and has_error that allow a query to react to the presence of error values that appear as a query is executing. However, at the moment this only allows for things like applying conditional logic while the query continues to run, and a user may not want to burn time letting an input stream be processed to completion after some error condition has been met. Fully instrumenting a query at every location an error value may appear also would come with a cost, which could be seen as a significant part of a debug effort early in the development of a sophisticated query. Therefore being able to invoke something like a -stoponerror flag could act as a blunt way for a user to weed out error conditions in such situations and/or continue using in production scenarios when errors can never be tolerated.
This feature overlaps somewhat in functionality with the one proposed in #5298, which seeks "early exit" as something that can be triggered by logic inside the query. Contrasting the two ideas:
Proposed #5298 exit operator |
Proposed -stoponerror |
|
|---|---|---|
| Where it's specified | a point in the pipeline you chose | outside the query entirely |
| What triggers it | a Boolean expression you wrote | any error value, including ones you never anticipated |
| What it stops | the current branch (and presumably the whole process if all branches have exited) | the whole process |
Design consideration
To halt when any error value is generated anywhere during the running of a query might be too blunt, since some queries might already contain logic to intentionally detect and react to errors. Therefore if we wanted to design this first with a single mission, perhaps we could tie it to just error values that reach the output writer. That said, with super in its current form, error values sometimes appear and get swallowed in ways that are difficult to notice (see #6696 for instance) so until we have confidence that errors always propagate reliably to output unless explicitly handled, perhaps the flag could offer modes like output and all.
- Lingua principale
- Go
- Stelle
- 1.6k
- Fork
- 84
- Merge medio
- 9h 55m
- PR unite (30g)
- 144
Preparare l'ambiente
- Nessun Dockerfile né 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 superdb/super
-
zeek reader: time/interval values with more than 9 fractional digits silently become 0; out-of-range values wrapForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertacommunity
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
superdb/super#7492 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 Mezza giornata Idoneità per principianti 58/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 22/100
I maintainer di solito rispondono entro 1 giorno
-
Pipe queries can no longer reach nested fields in typical Parquet filesForse già presa @nwt l’ha presa 3 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
superdb/super#7549 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di superdb/super
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
OneBusAway/maglev#1914 ·
I maintainer di solito rispondono entro 2 giorni
-
documentation needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
go good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
area: api bug severity:low
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Missing validation for port numbers exceeding valid TCP range (> 65535)Forse già presa @faizanfirdousi l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 80/100
llm-d/llm-d-inference-sim#853 ·
I maintainer di solito rispondono entro 1 giorno