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

Range archives might not be fully processed by core:archive #14889

Closed
sgiehl opened this issue Sep 11, 2019 · 0 comments · Fixed by #14890
Closed

Range archives might not be fully processed by core:archive #14889

sgiehl opened this issue Sep 11, 2019 · 0 comments · Fixed by #14890
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Milestone

Comments

@sgiehl
Copy link
Member

sgiehl commented Sep 11, 2019

When archiving runs for a range like last30 it's expected that all archives (for all plugins) are being processed. Currently it seems not all reports are being processed. For example all Event reports are not processed.

Steps to reproduce:

  • Set up a matomo site containing some tracked events for the last 30 days.
  • Disable browser triggered archiving in UI or in config
  • set [General] archiving_range_force_on_browser_request = 0 to disable automatic range archiving in normal requests
  • to ensure the range last30 is archived, selected it as default for a user or add [General] archiving_custom_ranges[] = last30 to config (last one only works with latest beta)
  • run ./console core:archive --force-idsites=1 and ensure something like this is in the output:
INFO [2019-09-11 13:38:32] 2049  Will pre-process for website id = 1, period = range, date = last30
INFO [2019-09-11 13:38:32] 2049  - pre-processing all visits
INFO [2019-09-11 13:38:41] 2049  Archived website id = 1, period = range, 0 segments, 1543 visits in last 30 ranges, 1543 visits this range, Time elapsed: 8.978s
  • Open Matomo and look at the events reports or requests them using API. Result will be empty, but should actually contain the event data for the range. Other reports work as expected
@sgiehl sgiehl added the Bug For errors / faults / flaws / inconsistencies etc. label Sep 11, 2019
@mattab mattab added this to the 3.12.0 milestone Oct 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants