[bgp]: Skip test_bgp_suppress_fib for suppress-fib dynamic-toggle race (#26175)

[deepak-singhal0408]

Description of PR

Summary:
Fixes #26175

Temporarily skip the whole bgp/test_bgp_suppress_fib.py module for the suppress-fib-pending dynamic-toggle race.

The module toggles suppress-fib-pending dynamically at runtime (via the shared config_bgp_suppress_fib() helper, no config reload). That triggers a race between orchagent, fpmsyncd and FRR where routes are intermittently not marked offloaded in FRR / not propagated to the upstream VM within the wait window, failing essentially every case in the module.

The root-cause fix makes suppress-fib-pending static (takes effect only after a config reload), removing the race — sonic-swss#4333, sonic-buildimage#26151, sonic-utilities#4361, sonic-mgmt#22916, SONiC#2335.

The product fix is master-only and is not backported. Because of that, the skip uses two different lift semantics, expressed as separate conditions:

• master — gated on the tracking issue: release in ['master'] and https://github.com/sonic-net/sonic-mgmt/issues/26175. When the fix lands on master and [bgp][test_bgp_suppress_fib] Whole module flaky on master & release branches — suppress-fib dynamic-toggle offload/propagation race #26175 is closed, the skip auto-lifts on master and coverage returns — no manual edit needed.
• 202505 / 202511 / 202605 — a plain release in [...] condition with no issue gate. These branches never receive the product fix, so the module is skipped for the life of the branch (same nature as the existing pre-202411 "not supported" condition).

Per-branch effect still requires cherry-picking this skip. Each release branch's nightly runs its own sonic-mgmt checkout, so this YAML change must be cherry-picked to 202505/202511/202605 for the skip to take effect there. The identical diff matches on each branch via its own release token.

If a release branch ever does receive the product fix, drop that branch's token from the release in [...] list — a deliberate per-branch edit. #26175 tracks the lifecycle.

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• New Test case
  • Skipped for non-supported platforms
• Test case improvement

Back port request

• 202205
• 202305
• 202311
• 202405
• 202411
• 202505
• 202511

(also 202605 — not listed in the template checkboxes; cherry-pick required there as well.)

Approach

What is the motivation for this PR?

The test_bgp_suppress_fib module is a persistent nightly-noise source across master and the active release branches. The dynamic runtime toggle of suppress-fib-pending races orchagent/fpmsyncd/FRR, so routes are intermittently left un-offloaded / un-propagated and nearly every case in the module fails intermittently. Skipping the module de-noises the nightly signal while the product-layer fix rolls out on master.

How did you do it?

Extended the existing bgp/test_bgp_suppress_fib.py skip block with conditions_logical_operator: or and split the affected releases by lift semantics:

conditions:
  - "release in ['201811', '201911', '202012', '202205', '202211', '202305', '202311', '202405']"
  - "release in ['202505', '202511', '202605']"
  - "release in ['master'] and https://github.com/sonic-net/sonic-mgmt/issues/26175"

The conditional_mark plugin replaces the issue URL with True/False based on the issue's open/closed state and eval()s the condition, so the master line auto-lifts when #26175 closes while the release-branch line stays permanent. (The same file already uses the <expr> and <issue-url> form for the asic_type in ['vs'] and #14449 conditions.)

How did you verify/test it?

• tests_mark_conditions.yaml parses cleanly and passes the check_conditional_mark_sort.py pre-commit hook.
• Simulated the conditional_mark evaluation for each release value:
  • issue open: master + 202505/202511/202605 all skip;
  • issue closed: master unskips, 202505/202511/202605 remain skipped — matching the intended lift semantics.

Any platform specific information?

None — the skip is keyed on release only (all ASICs/topologies), matching the all-vendor nature of the race.

Supported testbed topology if it's a new test case?

N/A — not a new test case; module skip only.

Documentation

N/A

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

@StormLiangMS @wangxin @yxieca A user wants to merge changes to the conditional mark files into master. Please review.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[deepak-singhal0408]

Cross-release flakiness context

Data from SonicTestData.V2TestCases (since 2026-03-15) shows this is not a single-branch issue — the suppress-fib dynamic-toggle race is present across release trains, and its rate is topology-dependent:

Branch	FRR	test_credit_loop fail %
202511	10.4.1	~10%
202605	10.5.4	~28%
master	10.5.4	~1% (t1-lag-only nightly coverage)

Notes:

• master's low rate is a coverage artifact, not immunity — its nightly runs this module almost exclusively on t1-lag (~1.2% fail over ~990 runs), where the race rarely fires. The failures concentrate on the heavier release-nightly topologies that master doesn't exercise at volume.
• The race is present on both 10.4.1 (202511, ~10%) and 10.5.4 (202605, ~28%) — it is a pre-existing flake, not a new failure on any one branch.

This is why the skip is kept permanent on 202511/202605 and only auto-lifts on master once the underlying fix lands.

[mssonicbld]

This PR has backport request for branch(es): 202505,202511.

Request label(s) for branch(es) 202511 already exists.
Added label(s) for branch(es) 202505.

_{---Powered by SONiC BuildBot}

[StormLiangMS]

LGTM

[mssonicbld]

@deepak-singhal0408 PR conflicts with 202605 branch

[mssonicbld]

This PR is approved for branch 202605. No cherry pick PR has been created because of code conflict. @deepak-singhal0408, please manually create the cherry pick PR.
If this change is already in 202605, please comment "already in 202605". Thanks!

_{---Powered by SONiC BuildBot}

[deepak-singhal0408]

This PR is approved for branch 202605. No cherry pick PR has been created because of code conflict. @deepak-singhal0408, please manually create the cherry pick PR.If this change is already in 202605, please comment "already in 202605". Thanks!

---Powered by SONiC BuildBot

created a manual cherry-pick PR. #26270

[mssonicbld]

The cherry pick conflict has been handled manually. Removing cherry pick conflict label...

_{---Powered by SONiC BuildBot}

[mssonicbld]

This PR has backport request for branch(es): 202505,202511.

Request label(s) for branch(es) 202511 already exists.
Added label(s) for branch(es) 202505.

_{---Powered by SONiC BuildBot}