-
Notifications
You must be signed in to change notification settings - Fork 906
fix: only disable route check for T2 #21582
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
Open
cyw233
wants to merge
2
commits into
sonic-net:master
Choose a base branch
from
cyw233:only-disable-route-check-on-t2
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.
Open
Conversation
This file contains hidden or 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
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
3f40b07 to
9720553
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ZhaohuiS
approved these changes
Dec 5, 2025
Contributor
ZhaohuiS
left a comment
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.
thank you for the quick fix!
Contributor
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ZhaohuiS
approved these changes
Dec 8, 2025
Signed-off-by: Chenyang Wang <[email protected]>
Signed-off-by: Chenyang Wang <[email protected]>
cfef952 to
8ee81d2
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
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 of PR
Change the
temporarily_disable_route_checkfixture logic to only apply to T2 topology for now.Summary:
Fixes # (issue) Microsoft ADO 36101536
Type of change
Back port request
Approach
What is the motivation for this PR?
The current disable-and-enable routeCheck monitor logic is causing test flakiness on some non-T2 platforms (see #16876 (comment)). Certain platforms require additional time to restart the routeCheck monitor, which can leave it inactive when the next test begins and result in false failures. We would like to address this issue urgently in this PR.
In a follow-up PR, I will properly enhance the
temporarily_disable_route_checkfixture so that:wait_until()timeout to verify the routeCheck status is as expected before proceeding to the next stepHow did you do it?
How did you verify/test it?
I ran the updated login on a non-T2 platform (Mx) and can confirm it's working well:

https://elastictest.org/scheduler/testplan/693272f7392767e9bf67e930
I also verified the logic on T2 platform and can confirm it's still having this logic: https://elastictest.org/scheduler/testplan/6932767fbcc3fac23371a83c

Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation