Thomas Eizinger
Thomas Eizinger
> To avoid unpleasant surprises for downstream, I think should introduce a new function rather than drastically changing the semantics of the current one. Open to other ideas, though. `send_fallible`?
> Sure. And presumably a recv version, too? I hadn't looked at `recv` at all. What can fail in receive that we currently don't expose? Doesn't `recv` only fail if...
Should I change the error type of `send` at the same time to return a custom error that makes it obvious that it only ever "fails" on `WouldBlock`?
> > Should I change the error type of `send` at the same time to return a custom error that makes it obvious that it only ever "fails" on `WouldBlock`?...
> The problem is that requests get executed concurrently, so in the worst case we might end up making the same request multiple times before one of them completes and...
Thank you @dgarus ! I hope to give this a review soon.
> @thomaseizinger Thank you so much for your efforts! Currently, I’m stuck with an integration test writing. The problem is what can i use as a webtransport client? I'm looking...
I think this is a great effort! I no longer maintain rust-libp2p but I am sure @jxs will be equally excited :)
Thank you for working on this! > One thought: using a dedicated action input like `cache: true` (defaulting to false) might be cleaner than checking for `--cache` in the args....
> @thomaseizinger wanna volunteer? 😬 Definitely! We are facing 429s on our daily cron suddenly and I am planning to see if the cache mitigates that.