`Stream`s issue unnecessary warning on close when Flutter hot restarts
ehuff700 opened this issue · comments
Describe the bug
Hey, thank you so much for this project.
I ran into a small issue with flutter hot restart when using a static StreamSink. Essentially on every hot restart the app will print out a "Fail to post message to Dart" message.
The reason why this happens is because when StreamSink is dropped, it calls the Drop implementation of the _closer field in it's StreamSinkBase struct.
My guess is that the infrastructure used to pass the close message is "down" or something along those lines, because the send_or_warn consistently fails everytime.
I am making this issue to discuss whether the error from send should simply be ignored in that specific context, since it doesn't make much sense to use send_or_warn (in my opinion).
MRE available here: https://github.com/ehuff700/frb-bug-mre.git
Steps to reproduce
Clone the MRE above and run with flutter run, observe the error message on hot restart. After debugging I tracked it down to the send_or_warn method in that specific Drop implementation.
Logs
N/AExpected behavior
No response
Generated binding code
No response
OS
No response
Version of flutter_rust_bridge_codegen
flutter_rust_bridge_codegen 2.0.0-dev.31
Flutter info
No response
Version of clang++
No response
Additional context
No response
Hi! Thanks for opening your first issue here! 😄
Hi, I guess one way is to detect this specific scenario and do not warn if it happens (since it is not a problem). However, I may not have enough time to immediately work on it, since it just prints a warning and does not cause big troubles - but if it causes real bugs feel free to ping me!
Hi @fzyzcjy, like you said this is just a warning and I don't think there are any bugs so this is really a small issue. I could make a PR for it, do you have any pointers on how we would detect a hot reload?
@ehuff700 Hi, thanks for the interest of PR! However, I am not sure whether there is an easy exact way to detect hot restart without any false positives. If there are scenarios when something really goes wrong but we do not realize today and make it non-warning, then we will lose a real warning and thus makes people hard to debug.