Only force single plugin archiving for root archive requests. #17250
Conversation
diosmosis
added
Bug
|
It would make sense. I couldn't think of an easy way to do it though, I'll think a bit more. |
|
@sgiehl added a test |
|
There seem to be some failing tests. Not sure if it related to the changes here. Besides that it looks good to merge |
| @@ -330,7 +330,9 @@ public static function getSelectableDoneFlagValues($includeInvalidated = true, P | |||
|
|
|||
| public static function isForceArchivingSinglePlugin() | |||
| { | |||
| if (!SettingsServer::isArchivePhpTriggered()) { | |||
| if (!SettingsServer::isArchivePhpTriggered() | |||
| || Loader::getArchivingDepth() > 1 | |||
There was a problem hiding this comment.
@diosmosis not sure yet I understand why Loader::getArchivingDepth() > 1 means we aren't forcing a single archive?
There was a problem hiding this comment.
this method is more "are we forcing archiving because pluginOnly=1" rather than "are we forcing the creation of a single plugin archive". when archiving depth > 1, then we're archiving a child period. in this case we want to use what's available and not "force archiving even if there's something usable there".
so if someone activates MultiChannelConversionAttribution, and it invalidates a month in the past, then we see that pluginOnly=1&plugin=MultiChannelConversionAttribution, we know we need to force archiving for that period, even if there is a 'done' or 'done.MultiChannelConversionAttribution' archive there. for the weeks inside, however, we assume they are already archived by core:archive and we don't want this branch to force archiving of a new week.
hope that makes sense...
Description:
If we don't do this, then no matter what, on pluginOnly archiving requests, we end up initiating archiving for subperiods, even if data exists.
Review