Is your feature request related to a problem? Please describe.
here is the output from having fastly log-tail up in a terminal for a few hours:
> fastly log-tail
INFO: Managed logging enabled on service 3wCN1FFZOpZsR30IqhSkpn
WARNING: error scanning response body: stream error: stream ID 101; PROTOCOL_ERROR; received from peer
stderr | 0331fdea | None?"/robots.txt"
stdout | 0331fdea | handled None?"/robots.txt" in 4350ns
stderr | 8083b6b5 | None?"/sitemap.xml"
stdout | 8083b6b5 | handled None?"/sitemap.xml" in 2787ns
stderr | 8083b6b5 | None?"/robots.txt"
stdout | 8083b6b5 | handled None?"/robots.txt" in 4616ns
WARNING: non-200 resp 404
ERROR: unrecoverable error, response code: 404.
If you believe this error is the result of a bug, please file an issue: https://github.com/fastly/cli/issues/new?labels=bug&template=bug_report.md
Describe the solution you'd like
The warning does not seem like something I should have to handle, and it's not clear to me if that's an API behavior related to my service's logs (though I assume it is not). eventually some API call here returned a 404 (but the API clearly does exist, since I can run this again with the same token and it's fine?)
I don't know what API semantics the log tailing endpoint has - is it a documented endpoint? /service/<sid>/log_stream/managed/instance_output doesn't seem to be. but I imagine the H2 stream error and outright 404 are part of just having a command like this; if there's a long-running request fetching logs, surely at some times the network will have a spurious reset because a server goes down for updates or something.
the CLI does handle 404, and 503 in some cases, so the fact that I get a 404 printed suggests that maybe there is some other API that returned a 404? honestly not sure what is happening in the output I've shared.
Describe alternatives you've considered
while true; do fastly log-tail --token $(cat ~/fastly.key); done
Additional context
this is part of what motivated me to open #1789 but I realized I was on a very old CLI and updated first, then log tailed and waited for it to happen again. that would put this at about 3-hours-to-reproduce IME.
Is your feature request related to a problem? Please describe.
here is the output from having
fastly log-tailup in a terminal for a few hours:Describe the solution you'd like
The warning does not seem like something I should have to handle, and it's not clear to me if that's an API behavior related to my service's logs (though I assume it is not). eventually some API call here returned a 404 (but the API clearly does exist, since I can run this again with the same token and it's fine?)
I don't know what API semantics the log tailing endpoint has - is it a documented endpoint?
/service/<sid>/log_stream/managed/instance_outputdoesn't seem to be. but I imagine the H2 stream error and outright 404 are part of just having a command like this; if there's a long-running request fetching logs, surely at some times the network will have a spurious reset because a server goes down for updates or something.the CLI does handle 404, and 503 in some cases, so the fact that I get a 404 printed suggests that maybe there is some other API that returned a 404? honestly not sure what is happening in the output I've shared.
Describe alternatives you've considered
Additional context
this is part of what motivated me to open #1789 but I realized I was on a very old CLI and updated first, then log tailed and waited for it to happen again. that would put this at about 3-hours-to-reproduce IME.