@tsteur opened this Issue on December 12th 2018 Member

I ran this command

./console core:archive --piwik-domain=foo.bar.baz --concurrent-requests-per-website=1 -- --force-idsites=1 --force-periods=day --skip-all-segments

and noticed it was archiving segments in the mysql processlist for all kind of reports. The queries were definitely caused by a regular API.get&trigger=archivephp.

Looking at a backtrace the segments might be archived because of https://github.com/matomo-org/matomo/blob/3.x-dev/plugins/Goals/API.php#L431-L441 but would have expected it wouldn't do a full archive anymore since https://github.com/matomo-org/matomo/pull/13105

@katebutler commented on May 5th 2019 Member

I've had a look at this (using data from the visitorgenerator) and been unable to reproduce.

@tsteur commented on May 5th 2019 Member

can't reproduce it either . Tested eg this way:

image

to ensure the archiving I first tracked a pageview, drop all this year's archiving table, set time_before_today_archive_considered_outdated=1 and made sure it actually archives, made sure it goes through the code referenced above, etc. and it all worked nicely.

I then removed the two lines https://github.com/matomo-org/matomo/pull/13105/files#diff-a3e66249463ecac225632c9b3a63d198R94 that process data for that segment and would have actually expected a failure and that it actually does process segments as the segments are being launched within the same archiving request.

This is odd, I really would have expected to see some archiving running for that segment. Then noticed the archiving fails when testing it in Goals\Archiver like this:
image

so the archiver is actually already smart enough by the looks to only archive that plugin when a segment is set, and not the others. Looks all good :)

This Issue was closed on May 5th 2019
Powered by GitHub Issue Mirror