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.
[efficiency-improver] perf: eliminate string[1] allocation per test case in discovery source tracking #16177
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
Uh oh!
There was an error while loading. Please reload this page.
[efficiency-improver] perf: eliminate string[1] allocation per test case in discovery source tracking #16177
Changes from all commits
f0b0a22b05acf0File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
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.
nit: [Error Reporting & Diagnostic Clarity] All per-source trace messages changed from
MarkSourcesWithStatus(plural) toMarkSourceWithStatus(singular). The new name is factually more accurate since the messages now live in the private helper, but it's a format change that would break any grep-based log analysis or support runbooks that match on the old prefix. No test currently asserts on these strings so nothing breaks in CI, but worth noting for ops / support docs.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.
[Parallel Execution & Scheduling Safety] The
_isMessageSentguard granularity regressed from per-test-case to per-batch.Before this PR, each
MarkSourcesWithStatus(new[] { ... }, ...)call checked_isMessageSentat entry. So ifTryAggregateIsMessageSent()fired on a concurrent thread mid-batch, the very next iteration caught it.Now the guard only lives at the top of
MarkSourcesBasedOnDiscoveredTestCases. IfTryAggregateIsMessageSent()races in after the method enters the loop, the entire remaining batch continues writing to_sourcesWithDiscoveryStatuseven thoughParallelDiscoveryEventsHandlermay already be executingGetSourcesWithStatus()on lines 89–92.Practical sequence:
_isMessageSent == 0) and begins iterating a batchTryAggregateIsMessageSent()(sets_isMessageSent = 1) then immediately callsGetSourcesWithStatus()to build the final reportMarkSourceWithStatus()for every remaining test case in the batchThose writes are "post-finalization" updates that weren't reflected in Thread B's snapshot. A source that should have been upgraded from
PartiallyDiscovered→FullyDiscoveredmid-batch may appear asPartiallyDiscoveredin the final report, which then incorrectly triggers the "discovery aborted" path atParallelDiscoveryEventsHandlerline 106.The ConcurrentDictionary doesn't corrupt, but the "Identical observable behaviour" and "No impact on thread safety" claims in the PR description aren't accurate for this concurrent scenario.
The race existed before (just narrower), so this is not a newly introduced bug — but it is a regression in the guard's effectiveness. The simplest fix is a mid-loop check:
Alternatively, document that the guard was intentionally coarsened to per-batch and add a test for
MarkSourcesBasedOnDiscoveredTestCases+TryAggregateIsMessageSentto pin the behaviour (analogous toMarkSourcesWithStatus_AfterMessageSent_ShouldSkipUpdate).Uh oh!
There was an error while loading. Please reload this page.