I'm too sleepy to file a proper bug report; but I just spent a good 30 mins debugging an issue that turned out to be related to temporaries: https://gist.github.com/yoshuawuyts/88bb552bb08ad5c1d53216c97fcc0f6e
These are all calls on the IncomingResponse
type - .consume().unwrap()
to get to the incoming body. Then .stream().unwrap()
to get to the actual byte stream. But if you don't assign them to a local variable, it apparently does an early drop which triggers a panic.
I'm not even sure this is a bug, and suspect it might just be an interaction between WIT's expressiveness limitations + our current limited stack trace / debugging facilities?
Not sure what to do with this; but I figured it'd be worth sharing at a minimum
If this tripped me up, it'll probably trip others up
While I can't say for certain this looks like you may be running into this behavior, which means you're right that WIT can't express the parent/child relationship here so the bindings can't do much better (at least not the auto-generated bindings)
ohhhh right
sorry, you linked to that earlier
and I didn't read the link - that's on me
I kind of forgot :sweat_smile:
yeah this looks like what I'm running into I think
haaaa
okay yeah that completely explains it
I think I'm so used to just relying on the Rust type system, that this kind of runtime dependency just really threw me
Yoshua Wuyts has marked this topic as resolved.
(I suspect this will resolve the issue; proactively closing it)
Ah yeah, that did do the trick!
It does lead to some fun cases like this tho:
/// An HTTP response
#[derive(Debug)]
pub struct Response {
bytes_read: u64,
content_length: u64,
headers: Vec<(String, Vec<u8>)>,
reactor: Reactor,
// IMPORTANT: the order of these fields here matters. `incoming_body` must
// be dropped before `body_stream`.
body_stream: InputStream,
incoming_body: IncomingBody,
}
heh good point! One thing you can do is to use ManuallyDrop
with a Drop
impl to explicitly write out the order of the drops (not that the struct field ordering doesn't work though)
oh yeah, good call
I don't know how yet; but we'll likely want to issue some guidance around this at some point
it sounds like this might be part of the current streaming model, and at least having a canonical one-pager to point at and say: "you're running into this case, do this thing" could be good
(I might volunteer doing that if we have a place to put it)
agreed would be good to have :+1:
Last updated: Dec 23 2024 at 14:03 UTC