fix #862 - unsub of a message ID that is already unsubbed#865
Conversation
…now work as expected
|
I appreciate that in the last couple of weeks we've seen three different loop structures to accomplish the same logic. While loop with an incrementer, for loop with a break, and now a for loop with dual exit condition. Way to keep things interesting! |
I don't know if you're genuinely excited or not-so-subtly indicating that we should choose one way and stick to it as much as possible :) |
|
I feel like we keep going around and around on this... (Sorry, I just couldn't resist!) |
|
@CDKnightNASA is this ready for a CCB review to get more inputs? |
CDKnightNASA
added
the
CCB:Ready
yes thx |
|
CCB 2020-08-09 APPROVED, How do we ensure we test and catch this? Open a new issue for creating a test. |
|
I opened #873 for the added test case. |
|
Added the test case in #875 |
yammajamma
added
IC-20200909
and removed
CCB:Ready
4 participants
Closes #862
Describe the contribution
After the changes implemented in #101, there may be routing table entries with no subscribers (RoutePtr->ListHeadPtr would be NULL.) This could cause a seg-fault. Also, even if there are entries in the routing table, there will be no event generated if the unsubscribe does not find a matching route entry.
Testing performed
Ran unit test (with updated event count.)
Expected behavior changes
Repeated unsubscriptions should function fine, generating an informational event if there is not a current subscription.
System(s) tested on
Debian 10.5
Contributor Info - All information REQUIRED for consideration of pull request
[email protected]