Skip to content
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

Only add site to list of sites to reprocess if only date being processed is today. #15154

Merged
merged 4 commits into from Nov 19, 2019

Conversation

diosmosis
Copy link
Member

@diosmosis diosmosis commented Nov 13, 2019

Quick fix for #15086 ... and fix for archive purging logic now that today dates are invalidated and temporary archives do not exist.

Fixes #15086
Fixes #10439

@diosmosis diosmosis added the Needs Review PRs that need a code review label Nov 13, 2019
@diosmosis diosmosis added this to the 3.13.0 milestone Nov 13, 2019
@tsteur
Copy link
Member

tsteur commented Nov 13, 2019

@diosmosis diosmosis added the not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. label Nov 14, 2019
@tsteur
Copy link
Member

tsteur commented Nov 15, 2019

@diosmosis I'm not sure this works as expected. I've been looking through the code for quite a while and been testing a few times and it seems like it's not reprocessing the data for today now.

image

Like here... What I did was tracking a request... then archive the data (no force-idsite param)... then tracked another request... expected it to archive again but because it wasn't invalidated and isOldReportInvalidatedForWebsite() returns false it was not archiving by the looks. Or maybe I'm understanding it wrong?

|| $firstArchiveValue == ArchiveWriter::DONE_OK_TEMPORARY
) {
// if there is more than one archive, the older invalidated ones can be deleted
if ($countOfArchives > 1) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change is definitely good to have I would say and should fix the deletion of a lot of archives 👍

@diosmosis
Copy link
Member Author

Like here... What I did was tracking a request... then archive the data (no force-idsite param)... then tracked another request... expected it to archive again but because it wasn't invalidated and isOldReportInvalidatedForWebsite() returns false it was not archiving by the looks. Or maybe I'm understanding it wrong?

It was working for me when I tested it last... I'll try and test it again.

@diosmosis
Copy link
Member Author

@tsteur I was able to get it to work after a while after realizing visitorgenerator sets forced datetimes. It was setting the value to maybe an hour or so in the past, but the last successful archive run was from ~10s ago when I ran it. When I removed the setForceVisitDateTime() method call in VisitorGenerator it started working.

After that I noticed one other issue, if you run multiple core:archives too quickly, it will skip archiving because not enough time has passed:

image

Notice it says tracking data found but also Skipped website id 1, already done 42s ago. I think these are probably unrelated issues.

@tsteur
Copy link
Member

tsteur commented Nov 17, 2019

@diosmosis I had tested it with a simple tracking request. Archive. Send a basic tracking request through a website using JS tracking. Triggered archiving again. I had set the interval between archives from 900s to 1s so that shouldn't have been an issue. Could you maybe double check?

@diosmosis
Copy link
Member Author

diosmosis commented Nov 18, 2019

@tsteur tested again, it works for me:

initial archive:
Screen Shot 2019-11-17 at 9 06 53 PM

initial visit count in log_visit:
Screen Shot 2019-11-17 at 9 09 51 PM

visit count after tracking:
Screen Shot 2019-11-17 at 9 10 21 PM

core archive after setting archive TTL to 1 (w/ a return 1 in Rules):
Screen Shot 2019-11-17 at 9 12 04 PM

@diosmosis
Copy link
Member Author

@tsteur if you could tell me what the reason for the site being skipped is, that might help.

@tsteur
Copy link
Member

tsteur commented Nov 18, 2019

@diosmosis sorry it works now indeed. Not sure why it didn't before. LGTM 👍

@diosmosis
Copy link
Member Author

@tsteur I hope it was just a failure to track or something that caused it to fail for you, because if it was the code at fault then it would probably be a timezone issue or something...

@diosmosis diosmosis merged commit 7ece9e1 into 3.x-dev Nov 19, 2019
@diosmosis diosmosis deleted the 15086-default-date-last branch November 19, 2019 06:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Review PRs that need a code review not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org.
Projects
None yet
2 participants