[TestFlexCounter] Use flag state rather than non-atomic counter for bulkChunksize test#1986
[TestFlexCounter] Use flag state rather than non-atomic counter for bulkChunksize test#1986justin-wong-ce wants to merge 1 commit into
Conversation
The existing `initialCheckCount` is not a reliable way to determine the state of the test-mocked configuration. This causes many racey conditions and makes the test flaky. An example would be a poll occuring in between test iterations where the `chunkSize` is being changed/ Swapping to use a callback-based flag to explictly set when the configuration is fully applied and when it is not. Signed-off-by: Justin Wong <jvwong@arista.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Unrelated CI fail: |
|
/azpw retry |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1161819: ✅Stage TestAsan:
✅Stage Test:
|
|
/azpw retry |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1161819: ✅Stage TestAsan:
✅Stage Test:
|
There was a problem hiding this comment.
Pull request overview
This PR updates the FlexCounter.bulkChunksize unit test to reduce flakiness by replacing the initialCheckCount-based “initialization vs runtime” heuristic with an explicit phase signal driven by a callback from the shared testAddRemoveCounter helper.
Changes:
- Add an optional
onSetupCompletecallback totestAddRemoveCounterand invoke it once the test’s FlexCounter/plugins/counters setup is complete. - Replace
initialCheckCountlogic inFlexCounter.bulkChunksizewith aruntimeReadyphase flag used by themock_bulkGetStatsimplementation. - Adjust bulk chunk size assertions to align with the new phase gating.
| uint32_t unifiedBulkChunkSize = 0; | ||
| int32_t initialCheckCount; | ||
| int32_t partialSupportingBulkObjectFactor; | ||
| bool runtimeReady = false; |
| if (unifiedBulkChunkSize > 0) | ||
| { | ||
| if (object_count != unifiedBulkChunkSize | ||
| && number_of_counters == allCounters.size() | ||
| && object_count > 1) | ||
| { | ||
| EXPECT_EQ(object_count, unifiedBulkChunkSize); | ||
| } | ||
| continue; | ||
| } | ||
| // Skip re-probe polls (single-object capability probes | ||
| // that happen after the merge-back, with object_count==1). | ||
| // The per-counter assertions below check steady-state | ||
| // per-prefix chunk sizes, which only apply when | ||
| // object_count > 1. This matches the documented intent | ||
| // in the comment above and the unified-path guard. | ||
| if (object_count == 1) | ||
| { | ||
| EXPECT_EQ(object_count, unifiedBulkChunkSize); | ||
| continue; | ||
| } |
| // non zero unifiedBulkChunkSize indicates all counter IDs share the same bulk chunk size | ||
| uint32_t unifiedBulkChunkSize = 0; | ||
| int32_t initialCheckCount; | ||
| int32_t partialSupportingBulkObjectFactor; |
|
@justin-wong-ce please review the copilot comments, esp the one about |
Ack, will be looking at this soon |
Description of PR
Summary:
The existing
initialCheckCountis not a reliable way to determine the state of the test-mocked configuration. This causes race conditions and makes the test flaky.An example would be a poll occuring in between test iterations where the
chunkSizeis being changed.Swapping to use a callback-based flag to explictly set when the configuration is fully applied and when it is not.
Fixes #1978
Type of change
Approach
What is the motivation for this PR?
FlexConuter.bulkChunksizeis flaky, causing many PR CIs to be flaky.Work item tracking
How did you do it?
Use a callback-flag mechanism to so that the test knows what to expect and what checks to run based on an explicitly known state.
How did you verify/test it?
Tests fully pass with
./tests --gtest_filter=FlexCounter.*-*addRemoveDashMeterCounter* --gtest_break_on_failure --gtest_repeat=100.Excluding the
addRemoveDashMeterCountertest since it is known to be flaky (#1985).Any platform specific information?
Documentation