Use of `wasi-http` fails to fully finish writing the body about componentizejs HOT 11 CLOSED

Oh, you need to call OutgoingBody.finish(outgoingBody) where you import the OutgoingBody in the import as it's a static method.

from componentizejs.

@brooksmtownsend makes sense, yes it is leaning entirely on the bindings model here. But also, in terms of things we might do to catch these types of issues:

1. For resources which require to be "explicitly dropped", we could provide a warning on the JS GC that warns that the resource was not explicitly dropped, and then at the end of the application lifecycle, provide these warnings.
2. For resources which require to be "explicitly consumed", we could have some kind of metadata which notes this and then instead of giving the warning above, instead give a warning with a suggestion of the consuming API method to use.

It's just a little bit of metadata but it could make the user experience a bunch better.

from componentizejs.

For easier testing, here is the raw JS:

import { ResponseOutparam, OutgoingResponse, OutgoingBody, Fields, } from "wasi:http/[email protected]";
// Implementation of wasi-http incoming-handler
//
// NOTE: To understand the types involved, take a look at wit/deps/http/types.wit
function handle(req, resp) {
    // Start building an outgoing response
    const outgoingResponse = new OutgoingResponse(new Fields());
    // Set the status code for the response
    outgoingResponse.setStatusCode(200);
    // Access the outgoing response body
    const outgoingBody = outgoingResponse.body();
    // Create a stream for the response body
    let outputStream = outgoingBody.write();
    // Write hello world to the response stream
    outputStream.blockingWriteAndFlush(new Uint8Array(new TextEncoder().encode("Hello from Typescript!\n")));
    // Set the created response
    ResponseOutparam.set(resp, { tag: "ok", val: outgoingResponse });
    OutgoingBody.finish(outgoingBody, undefined);
}
export const incomingHandler = {
    handle,
};

from componentizejs.

Just a note that I tried to recreate https://github.com/bytecodealliance/jco/blob/7b41c3551d26840a65682803e2c64810645ad732/test/fixtures/componentize/wasi-http-proxy/source.js#L32, and I see the comment there for TODO which might be causing the failure? Unsure

from componentizejs.

Yes, I believe you need to explicitly drop for WASI to work here - outputStream[Symbol.dispose]().

There's also an example of this in https://github.com/bytecodealliance/ComponentizeJS/blob/main/test/cases/http-request/source.js.

With the explicit resource management proposal (https://github.com/tc39/proposal-explicit-resource-management), and the enforcement of using being presented at TC39 tomorrow, this can be fully solved in future bindgen approaches.

But for now, yes it's a major footgun.

from componentizejs.

Hm I'm surprised, that kept the same behavior 🤔

import { ResponseOutparam, OutgoingResponse, Fields, } from "wasi:http/[email protected]";
// Implementation of wasi-http incoming-handler
//
// NOTE: To understand the types involved, take a look at wit/deps/http/types.wit
function handle(req, resp) {
    // Start building an outgoing response
    const outgoingResponse = new OutgoingResponse(new Fields());
    // Access the outgoing response body
    let outgoingBody = outgoingResponse.body();
    {
        // Create a stream for the response body
        let outputStream = outgoingBody.write();
        // Write hello world to the response stream
        outputStream.blockingWriteAndFlush(new Uint8Array(new TextEncoder().encode("Hello from Typescript!\n")));
        // @ts-ignore: This is required in order to dispose the stream before we return
        outputStream[Symbol.dispose]();
    }
    // Set the status code for the response
    outgoingResponse.setStatusCode(200);
    // Set the created response
    ResponseOutparam.set(resp, { tag: "ok", val: outgoingResponse });
}
export const incomingHandler = {
    handle,
};

I had to tell TS to ignore the warning but that's not a big deal. I'm glad to hear that TC39 will talk about this 🙂

from componentizejs.

Great, does that resolve the issue then for now at least?

from componentizejs.

@guybedford No it's the same behavior 😢 It didn't seem to affect the problem.

from componentizejs.

Also, if you want to actually stream the response, connect the stream by calling ResponseOutparam.set(resp, { tag: "ok", val: outgoingResponse }); earlier, before the stream is written to.

from componentizejs.

Calling OutgoingBody.finish(outgoingBody, undefined) was what I needed!

from componentizejs.

@guybedford just wanted to note that I'm gonna close this since my issue is resolved, but let me know if I can assist with updating the bindings to do this automatically. It feels generally like logic that is specific to resources and not ComponentizeJS, so it's implemented correctly here.

from componentizejs.