Fixed two issues with handling of processing dependent archives #20679
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:
Bugs fixed:
setting whether an archiving request is the root one or not as an instance property of Parameters does not work because when querying archive data for child periods, we will create entirely new instances (in CoreAdminHome\API::prepareArchive()). So instead, use a static variable. This properly prevents recursion here.
fix edge case where Goals initiates archiving far more than necessary when there are no conversions (so no data in goals reports) but there are visits (so archiving will still be executed). This was always an issue, but is is far more visible now since we aggregate one blob at a time, and thus query archive IDs once per report. So for every Goals report, we'd archive and try to process dependent archives, even though there are no conversions. And since there is no report data, nothing will be inserted, and we'll try to archive again when we move on to the next report.
See #20555
Review