By default WASI-Http response bodies can be consumed in an async streaming way which is not really compatible with Golem's general concept of not having to deal with transient errors explicitly.
The reason is that if the execution interrupts in the middle of consuming the async body, next time during recovering the worker state the request won't be re-sent and the already consumed body parts will be replayed, however, if the code decides to read one more chunk of the response body, it generates a failure as there is no open http connection to read from.
This means that by default any http response consumption (including the case when wasi-http is not used directly but for example by our reqwest fork or go implementation) have to be prepared to handle such errors and explicitly retry - golem's automatic retry won't help.
This can be improved by Golem's transaction control features - for example making the request and the body consumption one atomic operation using golem specific host functions.
I think a dedicated host function to disable response streaming would provide an even nicer user experience. If it's set, golem would guarantee to receive the whole response body at the same time it sends the request (and then provide the same async stream interface as usual), which guarantees that reading the response body would never fail even if there was a worker restart.
By default WASI-Http response bodies can be consumed in an async streaming way which is not really compatible with Golem's general concept of not having to deal with transient errors explicitly.
The reason is that if the execution interrupts in the middle of consuming the async body, next time during recovering the worker state the request won't be re-sent and the already consumed body parts will be replayed, however, if the code decides to read one more chunk of the response body, it generates a failure as there is no open http connection to read from.
This means that by default any http response consumption (including the case when wasi-http is not used directly but for example by our reqwest fork or go implementation) have to be prepared to handle such errors and explicitly retry - golem's automatic retry won't help.
This can be improved by Golem's transaction control features - for example making the request and the body consumption one atomic operation using golem specific host functions.
I think a dedicated host function to disable response streaming would provide an even nicer user experience. If it's set, golem would guarantee to receive the whole response body at the same time it sends the request (and then provide the same async stream interface as usual), which guarantees that reading the response body would never fail even if there was a worker restart.