-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Fix invariant violation if we get a message without piggyback ack while expecting an ack. #23282
Fix invariant violation if we get a message without piggyback ack while expecting an ack. #23282
Conversation
…le expecting an ack. Such messages are not allowed per spec, so we should just ignore them. Fixes project-chip#22854
PR #23282: Size comparison from d7cd5aa to a5a4b20 Increases (17 builds for bl602, bl702, efr32, esp32, linux, psoc6, telink)
Decreases (3 builds for cyw30739, k32w, qpg)
Full report (38 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
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.
Thanks for the fix!
The test failures are somewhat real in the sense that we have tests that manually remove (some but not enough) retrans table entries and then send two messages in a row on the same exchange without having gotten a reply to the first one (which gets dropped in the test). Those tests need adjusting to deal with this behavior, because they are in fact relying on these messages getting delivered to the other side and the other side responding. @turon I tried just clearing all the retrans entries, but then that drops the exchange on the server entirely, and we actually get different behavior because an injected unexpected Status Response message is handled differently depending on whether it matches a closed but still alive exchange or does not match any exchange at all. In the latter case, @yunhanw-google do you have time to sort out how these tests (TestReadInteraction, TestWriteInteraction, TestCommandInteraction) should handle this? |
3da0c51
to
683f467
Compare
PR #23282: Size comparison from 0998742 to 683f467 Increases (46 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
Decreases (6 builds for cc13x2_26x2)
Full report (49 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
I decided to fix the tests to make it look like a response from the server had in fact been received and just ignored at the data model layer instead of dropped at the message layer. That means:
|
…le expecting an ack. (project-chip#23282) * Fix invariant violation if we get a message without piggyback ack while expecting an ack. Such messages are not allowed per spec, so we should just ignore them. Fixes project-chip#22854 * Fix tests. * Address review comment.
…le expecting an ack. (project-chip#23282) * Fix invariant violation if we get a message without piggyback ack while expecting an ack. Such messages are not allowed per spec, so we should just ignore them. Fixes project-chip#22854 * Fix tests. * Address review comment.
…le expecting an ack. (project-chip#23282) * Fix invariant violation if we get a message without piggyback ack while expecting an ack. Such messages are not allowed per spec, so we should just ignore them. Fixes project-chip#22854 * Fix tests. * Address review comment.
…le expecting an ack. (project-chip#23282) * Fix invariant violation if we get a message without piggyback ack while expecting an ack. Such messages are not allowed per spec, so we should just ignore them. Fixes project-chip#22854 * Fix tests. * Address review comment.
Such messages are not allowed per spec, so we should just ignore them.
Fixes #22854