The cookbook example "Accessing HTTP Response Metadata While Streaming" doesn't stream
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 58/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- shell
- Domain
- documentation
Research direction
Start with the cookbook example titled "Accessing HTTP Response Metadata While Streaming" and reproduce it against https://example.com. Determine a cleaner streaming form than the shown $in or conditional-expression workarounds; done means the status and content type are printed while the HTTP body remains available to the following lines command.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- TypeScript
- Stars
- 258
- Forks
- 561
- Avg merge
- 3h 20m
- Merged PRs (30d)
- 15
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nushell/nushell.github.io
-
Difficulty 1/5 1-3 hours Newbie friendliness 68/100
nushell/nushell.github.io#2081 · 3 comments ·
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
nushell/nushell.github.io#767 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
nushell/nushell.github.io#2209 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
nushell/nushell.github.io#2194 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 48/100
nushell/nushell.github.io#2155 · 1 comment ·
All issues in nushell/nushell.github.io
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
modelcontextprotocol/inspector#2458 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
railmapgen/rmp-gallery#4068 ·
-
Mend: dependency security vulnerability status: needs triage 🕵️♀️
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
carbon-design-system/ibm-products#9907 ·