The cookbook example "Accessing HTTP Response Metadata While Streaming" doesn't stream
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 58/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- shell
- Ambito
- documentation
Direzione di ricerca
Inizia con l'esempio del cookbook intitolato "Accessing HTTP Response Metadata While Streaming" e riproducilo con https://example.com. Determina una forma di streaming più pulita rispetto alle soluzioni alternative mostrate con $in o un'espressione condizionale; il lavoro è completato quando lo stato e il tipo di contenuto vengono stampati mentre il corpo HTTP rimane disponibile per il comando lines successivo.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The example in question is:
http get --allow-errors https://api.example.com/events.jsonl
| metadata access {|meta|
print $"Status: ($meta.http_response.status)"
print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)"
if $meta.http_response.status != 200 {
error make {msg: $"Failed with status ($meta.http_response.status)"}
} else { }
}
| lines
| each { from json }
| where event_type == "error"
This won't work because the input to the closure is fed to the first statement, which is print $"Status: ...", while the closure output is taken from else {}. If the http response status is 200, the closure will always output nothing because the input for the closure was consumed by print. We can't test this because api.example.com is a fake subdomain, so let's modify the example to use example.com and not assume the output is json:
http get --allow-errors https://example.com
| metadata access {|meta|
print $"Status: ($meta.http_response.status)"
print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)"
if $meta.http_response.status != 200 {
error make {msg: $"Failed with status ($meta.http_response.status)"}
} else { }
}
| lines
If you run this, you will see that the status and content type are printed, but the http body is not returned from the closure.
One solution is to use the $in variable to collect the input and return it from the else statement:
http get --allow-errors https://example.com
| metadata access {|meta|
let input = $in
print $"Status: ($meta.http_response.status)"
print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)"
if $meta.http_response.status != 200 {
error make {msg: $"Failed with status ($meta.http_response.status)"}
} else { $input }
}
| lines
This does return the http body from the closure, but the example is called "Accessing HTTP Response Metadata While Streaming", and $in collects the input, so it's no longer a stream.
If we want to make this work while streaming, we can make the if statement into the only top level statement of the closure by moving the print statements into its conditional expression:
http get --allow-errors https://example.com
| metadata access {|meta|
if (
print $"Status: ($meta.http_response.status)";
print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)";
$meta.http_response.status != 200
) {
error make {msg: $"Failed with status ($meta.http_response.status)"}
} else { }
}
| lines
When run, this streams the http body after printing the status and content-type. However, it is pretty hacky. If we were to put this in the cookbook, it would need an accompanying explanation as to how sticking statements in the conditional expression prevents them from eating the closure input. Perhaps someone with more nushell experience than me can come up with a cleaner way to write this?
- Lingua principale
- TypeScript
- Stelle
- 258
- Fork
- 561
- Merge medio
- 3h 20m
- PR unite (30g)
- 15
Guida per i contributori
Apri 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 nushell/nushell.github.io
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 68/100
nushell/nushell.github.io#2081 · 3 commenti ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 62/100
nushell/nushell.github.io#767 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
nushell/nushell.github.io#2209 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
nushell/nushell.github.io#2194 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 48/100
nushell/nushell.github.io#2155 · 1 commento ·
Tutte le issue di nushell/nushell.github.io
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
area:tools bug good first issue help wanted priority:P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
TaewoooPark/Motifcode#14 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
newrelic-experimental/preflight#793 · 1 commento ·
-
bug 🐞
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
BasedHardware/omi#15320 ·