-
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
[SVE] TC-MCORE-FS-1.3: Bump the DUT timeout for newly added device #35740
Conversation
Review changes with SemanticDiff. Analyzed 1 of 1 files. Overall, the semantic diff is 3% smaller than the GitHub diff.
|
PR #35740: Size comparison from 1597be7 to eef4a94 Full report (88 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
@samadDotDev how did you create this PR? It runs double the CI for some reason, and I believe it may be that it uses a main repo branch instead of a fork. Could you confirm? Could you please switch to using forks for development? |
PR #35740: Size comparison from 2651245 to 1d26d39 Full report (32 builds for cyw30739, linux, nrfconnect, nxp, psoc6, qpg, stm32, tizen)
|
…roject-chip#35740) * Bump the DUT timeout for discovering and commissioning newly added device * Update src/python_testing/TC_MCORE_FS_1_3.py --------- Co-authored-by: Andrei Litvin <[email protected]>
This timeout is pretty short because right after issuing the
CommissionerControlCluster::ReverseOpenCommissioningWindow
command, the DUT is expected to discover the newly advertised_matterc._udp
service, resolve its address, establish PASE, install theDUT_FSA
's fabric, subscribe (& perform other necessary interactions during onboarding) before making it available as a newly accessible bridged node on theDUT_FSA
's aggregator parts list, and some of these operations can take a bit of time.Bumping up to 30s, consistent with a few other FS test cases.
Fixes #35739