-
Notifications
You must be signed in to change notification settings - Fork 471
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
agreement: update AttachReceivedAt to handle compound (PP) messages #5142
agreement: update AttachReceivedAt to handle compound (PP) messages #5142
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5142 +/- ##
=======================================
Coverage 53.45% 53.46%
=======================================
Files 431 431
Lines 54364 54368 +4
=======================================
+ Hits 29061 29066 +5
+ Misses 23049 23048 -1
Partials 2254 2254
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
c7ea113
to
e5d0e59
Compare
…ceivedValidatedAt
e5d0e59
to
d1133ff
Compare
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 did not dig deep into assertCorrectReceivedAtSet
but the new AttachReceivedAt
looks safe and valid.
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.
Read through both changes and the tests and it looks good to me.
Summary
PP messages in the first period are compound messages, containing both a vote and a proposal, which are converted into a special
messageEvent
bysetupCompoundMessage()
with a structure like this:In TestPlayerRetainsReceivedValidatedAt in #5041 I was only testing sending in two separate vote and proposal
messageEvent
s, not a single compoundmessageEvent
like this, and so I missed this important case when attaching receivedAt timings.Test Plan
add some additional player tests that send in messageEvents with non-nilWill do this in separate PR — requires updating the rest of player_test.goTail
fields for additional coverageupdate testing helper functionWould require updating other player_test.go tests that rely on the current getTrace().Contains() behavior, will do in separate PRgetTrace().Contains(ev)
to do a more thorough job comparing all the fields of expected events/actions against the trace, instead of just the action type. This would have helped me catch this more quickly (for example complaining that the verifyVote action's TaskIndex was not the same as the expected value I was passing intoContains()
)