Can't read to EOF on BufReader returned from get_descriptor()

[allisonkarlitskaya]

If you call ImageProxy::get_descriptor() and try to call .read_to_end() on the returned impl AsyncBufRead then you'll stall forever.

    let (mut blob_reader, driver) = self.proxy.get_descriptor(&self.img, &descriptor).await?;
    blob_reader.read_to_end(&mut raw_config).await?;  // <- gets stuck here
    driver.await?;

Looking at the example code in the repository, you can see that something like this works, however:

    let (mut blob_reader, driver) = self.proxy.get_descriptor(&self.img, &descriptor).await?;
    let mut raw_config = vec![];
    let (a, b) = tokio::join!(blob_reader.read_to_end(&mut raw_config), driver);
    a?;
    b?;

It would be cool if either:

• the 'naive' approach worked; or
• what you need to do with the return values got documented as part of the function docs

[cgwalters]

This is related to ostreedev/ostree-rs-ext#657

[cgwalters]

We chatted about this realtime but the basic issue right now is that the proxy is the thing doing checksum verification, and I didn't want to present "checksum mismatch" as "final error on read".

So today driver represents "final work apart from reading the raw data".

The other thing one needs to understand is that in async rust futures don't make progress unless polled and when doing

blob_reader.read_to_end(&mut raw_config).await?;
driver.await?;

The driver async task isn't polled until the first completes, but join will poll both to ensure they both progress.

[allisonkarlitskaya]

We chatted about this realtime but the basic issue right now is that the proxy is the thing doing checksum verification, and I didn't want to present "checksum mismatch" as "final error on read".

That makes a lot of sense, which is why I make sure to await driver and check for an error before actually using the data... but having a Read impl that deadlocks when you try to read it to the end unless you're also polling on another awaitable is definitely a bit on the weird side...

[allisonkarlitskaya]

fwiw, I'd find the "final error on read" approach to be quite reasonable. I guess your reasons there are something like not wanting to have to shoe-horn the error into the standard io error type? I think I read somewhere that you can optionally chain additional errors there somehow...?