"Fire and forget" option for outbound HTTP

[radu-matei]

I would like to be able to kick off a request but not wait for its response using the outbound HTTP API.

[itowlson]

For this, is the requirement:

1. I kick off an HTTP request, and care nothing for its fate; if I exit a moment later and the server goes "connection dropped, abandon processing" then so be it; or
2. I kick off an HTTP request, and care that the server processes it fully, but am not worried enough about failures to block on a response.

I am guessing case 2 is what's needed, but am checking because we have seen Spin handlers killed on client drop, so that might require that we keep the client alive in the host even if the Wasm module has exited, I am not sure.

[radu-matei]

Sorry, I was in a bit of a rush when I filed the issue, here is a bit more context here.

There are interactive operations that have an aggressive timeout for receiving a response — for example, Slack slash commands expect their webhook handler to return an HTTP response within 3 seconds — which means that if I want to kick off an operation with an outbound HTTP call that takes longer than that then return something back to the original request, there is currently no way to achieve this with a Spin component, as outbound HTTP calls will always wait for the response to finish.

I think this is close to option 2 in your list above.

[rylev]

It seems like the general way to think about this is that we want the spin handler to live past when the request is returned. Right now the spin component's lifetime is tied directly to the request/response. Instead what you seem to be asking for is a way to break that relationship and allow spin handlers to run after they've returned a response.

[radu-matei]

Take the following example:

• I have an internal API that accepts an HTTP request, then kicks off processing for a long period of time. It might return after it's finished processing, or it might never return. This is not necessarily a Spin component.
• I have a public Spin component that accepts requests and needs to kick off the internal processing job by sending a request to the previous API. Currently, the outbound HTTP implementation in Spin always awaits the response of the outbound HTTP request it sent. Which means that we can't build a scenario where we return a 202 status from the Spin application and stop the Spin component, because we are waiting for the response from the internal API which might come after a long period of time.

So the ask in this scenario is to be able to send an outbound HTTP request but not wait for its response.

Decoupling a component's lifetime from the request/response model is something I'd like to explore at some point, but this feature request is narrow specifically for outbound HTTP.

Does this help clarify the scenario a bit?

[lann]

This is done as I understand it. The wasi-http incoming handler lets you send a response and continue processing. See e.g. https://github.com/spinframework/spin-rust-sdk/blob/196e7438b66773affd23cd7e95b8d6fd0bf0d766/src/http.rs#L122-L152

[lann]

This sounds like sendBeacon from the browser world, which can notably keep working after a page is closed.