Fix empty report feedback loop edge-case #35899
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Review changes with SemanticDiff. |
jmartinez-silabs
approved these changes
Oct 3, 2024
|
PR #35899: Size comparison from 6bb8645 to b57e399 Full report (88 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
andy31415
approved these changes
Oct 4, 2024
yyzhong-g
pushed a commit
to yyzhong-g/connectedhomeip
that referenced
this pull request
Dec 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
When using the Synchronized report scheduler, it was possible to hit an edge-case where the device would fall into a feedback loop sending reports if it has more than two subscriptions.
The edge-case can happen (how the bug was found) when the publisher has 2 or more subscriptions.
Fundemental issue is a ReadHandler was being marked as CanBeSynced (line#190) when it is already waiting for a response.
Since it is already waiting for a response, it is already synced and does not need to be synced once again.
Testing
Manual testing
Due to the nature of the "multi-task" trigger that needs to happen back to back to trigger the bug, i was not able to unit test this exact scenario. The bug was triggered when a seperate task from the chip task was causing the attributes of the subscriptions to be marked dirty.