[action] [PR:28531] [system_health]: Adapt process-exit test wait to platform polling_interval

[mssonicbld]

Description of PR

Summary:
test_service_checker_with_process_exit hard-coded a 180s wait (WAIT_TIMEOUT) for healthd to record a stopped critical process in STATE_DB SYSTEM_HEALTH_INFO. On BMC platforms (e.g. Nokia-7220-Th6p-2-bmc / arm64-nokia_bmc_h6_128-r0), healthd polls on a 300s interval and reloads config only on the next loop. Because 180s < the 300s poll interval, the record never appeared in time and the test failed with AssertionError: <process> is not recorded.

The fix is BMC-specific: only on BMC platforms (duthost.is_bmc()) is the wait derived from the real config via get_system_health_config(duthost, 'polling_interval', FAST_INTERVAL) and set to max(WAIT_TIMEOUT, polling_interval * 2) so a poll loop boundary is guaranteed to be crossed. All other platforms keep the original 180s WAIT_TIMEOUT behavior unchanged. This mirrors the duthost.is_bmc() conditional already used by test_external_checker, and WAIT_TIMEOUT is unchanged globally.

Fixes # (issue)

Type of change

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

Back port request

• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605
• 202608

Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO):
Failure type: regression

Tested branch

• master
• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605
• N/A

Test result

Approach

What is the motivation for this PR?

test_service_checker_with_process_exit was failing on BMC platforms because its hard-coded 180s wait is shorter than the platform's 300s healthd polling_interval, so the stopped process was never recorded before the wait expired (AssertionError: <process> is not recorded).

How did you do it?

Gate the longer wait behind duthost.is_bmc(). On BMC, read the platform's configured poll interval with get_system_health_config(duthost, 'polling_interval', FAST_INTERVAL) and use wait_timeout = max(WAIT_TIMEOUT, polling_interval * 2) (two poll loops plus margin, never shorter than the previous default). Non-BMC platforms fall through to the original WAIT_TIMEOUT. This follows the same duthost.is_bmc() pattern already used by test_external_checker. WAIT_TIMEOUT is left unchanged for other tests.

How did you verify/test it?

python -m py_compile and flake8 --max-line-length=120 both pass clean on the file. The logic mirrors the already-passing test_external_checker (BMC conditional) and test_service_checker (polling_interval-derived wait).

Any platform specific information?

Only BMC platforms where healthd polling_interval defaults to 300s (e.g. Nokia-7220-Th6p-2-bmc / arm64-nokia_bmc_h6_128-r0) are affected. Non-BMC platforms retain the exact previous 180s wait behavior.

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

N/A — existing test.

Documentation

N/A

Signed-off-by: Sonic Build Admin sonicbld@microsoft.com

[mssonicbld]

Original PR: sonic-net/sonic-mgmt#28531

[azure-pipelines]

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

[mssonicbld]

/azp run

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.