-
Notifications
You must be signed in to change notification settings - Fork 639
fix: Destroying execution environment streams should emit events #3074
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
e850acc to
42e9cfc
Compare
42e9cfc to
06b355d
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3074 +/- ##
==========================================
+ Coverage 98.27% 98.29% +0.02%
==========================================
Files 417 417
Lines 11759 11759
Branches 1827 1827
==========================================
+ Hits 11556 11559 +3
+ Misses 203 200 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| try { | ||
| !stream.destroyed && stream.destroy(); | ||
| stream.removeAllListeners(); | ||
| stream.destroy(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if we should still check !stream.destroyed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought I had found evidence that you could call it multiple times without issue, but I can't find it now. Will just re-add the check
Previously we would remove event listeners when calling
destroy. This meant that consumers of our streams would not be notified that the stream was closed causing issues likeCannot call write after a stream was destroyed.Instead, we want consumers to be notified when a stream is torn down. One issue however is that it introduces new issues where some code paths throw
Premature close. This seems to be an underlying problem in the MetaMask stream architecture and the error message is ignored on the extension client. We do the same here.This will eventually also allow us to remove
closeConnectionsfrom the SnapController constructor.