-
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
Delay the commissioning window ended check by one second #37352
Open
Apollon77
wants to merge
1
commit into
project-chip:master
Choose a base branch
from
Apollon77:patch-10
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+2
−1
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
The test plan states that the test should wait till the time is over. The current test waits exactly as long as the window is. If there are cases where on the DUT the timers are not that accurate this "very exact check" could lead to false positives. We had such cases with matter.js in the CI here and there because Node.js Timers are not 100% accurate and depending on other tasks in the event loop closing the window could be slightly delayed. One CI example can be seen in https://github.com/project-chip/matter.js/actions/runs/12964616630/job/36163527843#step:4:3695 The analysis of a comparable showed this: * 10:17:46.984 matter.js enables the timer for 180s * 10:17:46.987 matter.js send InvokeResponse * 10:17:46.989 till 10:20:46.989 test-runner wait, so exactly 180s * 10:20:46.992 we get the read and we are still on "window opened" * 10:20:46.994 we close the window - 10:20:46.996 trx is unlocked so done So the test did the read 4ms too early. This proposal could make this test a bit more false positive secure also for prodiction certifications.
PR #37352: Size comparison from 95d5de5 to 521c19e Full report (72 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
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.
The test plan states that the test should wait till the time is over. The current test waits exactly as long as the window is. If there are cases where on the DUT the timers are not that accurate this "very exact check" could lead to false positives.
We had such cases with matter.js in the CI here and there because Node.js Timers are not 100% accurate and depending on other tasks in the event loop closing the window could be slightly delayed.
One CI example can be seen in https://github.com/project-chip/matter.js/actions/runs/12964616630/job/36163527843#step:4:3695
The analysis of a comparable showed this:
So the test did the read 4ms too early.
This proposal could make this test a bit more false positive secure also for production certifications. The test and the exact timers in the test runner are "too exact" in my eyes and giving the DUT one second more time should not bring any harm but reduce false positives.
Testing
This is a test itself. It is not executed in CI. I tested it manually locally