Thomas Eizinger comments

Results 1888 comments of


                                            Thomas Eizinger

DNS Aliases

> We may want to consider putting all these domains under `firezone.dev` (or some other domain we control) to make sure TLS works if the user wants to use TLS....

`.local` is for mDNS and will likely cause problems. `.internal` has just been reserved though so that could be an option: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en#section2.a

Only return `Poll::Ready` from `Sender::poll_flush` if the channel is empty

Miri is detecting a deadlock but I am not quite sure why. Help is much appreciated.

Only return `Poll::Ready` from `Sender::poll_flush` if the channel is empty

Okay, I think I found the problem. `SinkExt::send` implies `flush` which caused a deadlock if we have a task that suspends on `send` and doesn't at the same time read...

Only return `Poll::Ready` from `Sender::poll_flush` if the channel is empty

Not sure why https://github.com/rust-lang/futures-rs/actions/runs/5046514587/jobs/9052136457?pr=2746#step:5:326 is failing. It passes locally. Help would be appreciated.

Only return `Poll::Ready` from `Sender::poll_flush` if the channel is empty

> > This makes me wonder whether this might perhaps be a fairly intrusive change for the ecosystem. > > Yeah, I'm not open to introducing a patch that may...

fix: don't fail when `finish` is called on a stopped stream

I added to commits that make the test pass. Let me know if this fix is okay :)

fix: don't fail when `finish` is called on a stopped stream

> Thanks for the PR! I'd like to discuss the motivation in some more depth. Thank you for the comment. I'll try to expand a bit. > > Whilst [not...

fix: don't fail when `finish` is called on a stopped stream

Thank you for the clarification! It seems that the safe thing to do is to instantly close the stream once we are done with writing _before_ we start reading data...

fix: don't fail when `finish` is called on a stopped stream

> > Or maybe it should return something other than Result > > This is a good thought. On review of the API, I think any form of async, data-bearing...