This implementation only accepts a single argument and thus only supports zero-delay tasks, which we run after calling the app's HTTP request handler and resolving the promise it returns.
I couldn't come up with a useful, simple way to integration test this, since the tasks are only run after the HTTP handler has finished. At that point, the only thing a task can do to affect the response is throw an exception that propagates as a Rust error so that the Rust SDK returns a 500. Tasks can also have side effects like making outbound HTTP requests, so we could test that, but it would require spinning up a test HTTP server, which seems like overkill for the time being.
This implementation only accepts a single argument and thus only supports zero-delay tasks, which we run after calling the app's HTTP request handler and resolving the promise it returns.
I couldn't come up with a useful, simple way to integration test this, since the tasks are only run after the HTTP handler has finished. At that point, the only thing a task can do to affect the response is throw an exception that propagates as a Rust error so that the Rust SDK returns a 500. Tasks can also have side effects like making outbound HTTP requests, so we could test that, but it would require spinning up a test HTTP server, which seems like overkill for the time being.
Signed-off-by: Joel Dice joel.dice@fermyon.com