Currently we check if a segment has been created or updated since the last time we invalidated in core:archive, and if so invalidate in the past. This is more complicated and error prone, it is far easier to just invalidate in the past in the SegmentEditor API.
Wondering if updating that behavior could lead to egde cases on update. E.g. if someone has a cron running only once nightly. After the cron ran a segment is changed and afterwards Matomo is update to that new behavior. The one changed segment won't get invalidated anymore, right? Would we need to do that once in an update maybe? 🤔
@sgiehl that makes sense, I'll add an update to check as well.
@sgiehl test should be fixed w/ the next build. the last change increases the amount of invalidated dates for segments, which I think is a bug fix. Before we were checking if the segment was created/edited after the earliest date for rearchiving, but it doesn't make sense to do that when invalidating for any report and not invalidating because of a segment.
All good from my side. 👍
@sgiehl fyi, fixed the tests and in doing so found another bug in the ArchiveInvalidator class. Before we were removing queued invalidations from tracking when invalidating any non-range period. But this meant that if we invalidated just a week, the day wouldn't get re-archived, even if there was a new visit.
Will wait to merge in case you want to do a new review of the change.