-
Notifications
You must be signed in to change notification settings - Fork 78
=receptionist Fix receptionist crash on concurrent registrations; those are fine and expected #1059
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
|
Joining timeout in |
|
Seems to be same as #1034 - the nodes seem to sometimes need longer to join up for the test. |
|
Integration test is green which is good, this one would have triggered the bug this is fixing :-) |
yim-lee
left a comment
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.
One typo but otherwise LGTM 👍
| } | ||
| let key = DistributedReception.Key(Guest.self, id: keyID) | ||
|
|
||
| await self.whenLocal { myself in |
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.
This reads very nicely 👍
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 recently realized we don't always have to do the __ trickery by the way :)
Sources/DistributedActors/Cluster/Reception/OperationLogDistributedReceptionist.swift
Outdated
Show resolved
Hide resolved
| // incoming registration version was already seen, and thus we don't need to emit it again | ||
| return false | ||
| case .happenedAfter: | ||
| case .happenedAfter, .concurrent: |
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.
Ah, makes sense I think.
…butedReceptionist.swift Co-authored-by: Yim Lee <[email protected]>
New receptionist was too aggressive in what it deemed acceptable to be send onNext to the reception stream.
Concurrent messages are fine; specifically if [first:1] then [first:1, second:1] happens, these may have been concurrent in vector clock meaning, but it means that the event has more information so we should be emitting it
Actual fix is
cc51dba(#1059) and the rest is supporting infraresolves #1053