Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[event-hubs] fix uncaught TypeError #8884
[event-hubs] fix uncaught TypeError #8884
Changes from 11 commits
aaaaca2
599617b
a76d992
37358ce
8369442
a9baa6e
06b8e4e
1bb978a
c98f6cf
00943d7
883325d
eb0e0f2
f462956
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
So...beautiful.....
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 wish I could take credit but that's right out of the TypeScript handbook: https://www.typescriptlang.org/docs/handbook/advanced-types.html#distributive-conditional-types
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.
It looks like the
isDisconnecting
variable is basically the same aswaitForDisconnectPromise != null
. Worth it to remove and just have the one variable to track if we're disconnecting?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.
Yeah...I have a check in readyToOpenLink() that checks
isDisconnecting
, which just felt easier to understand thanif (waitForDisconnectPromise)
orif (Boolean(waitForDisconnectPromise))
, but it might be better to have one source of truth.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.
Updated!
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.
Why is this if check removed?
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.
It's possible for
disconnected
to be emitted while connecting. For example, if the connection is viewed as being idle while the connection is still in the process of opening. This check was preventing us from closing the existing senders in this scenario.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 think this check is a remnant of the time when we recovered sender links when connection was disconnected. So the code below where we have
sender.close()
was previouslysender.onDetached()
. Since that need to be done if the sender is already connecting, we had this check. It should have been removed when we made the decision to not re-connect broken sender links in the background i.e. in #6737