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

Fix for current year not processed for new custom reports #19569

Merged
merged 3 commits into from Aug 8, 2022

Conversation

bx80
Copy link
Contributor

@bx80 bx80 commented Jul 26, 2022

Description:

Steps to recreate:

  1. Create a new custom report, add any dimension/metric
  2. Run ./console core:archive
  3. Check the output for period = year - only the previous year is processed, not the current year.

When archiving starts for a custom report, a check is done for any existing archives and if missing then invalidations are created for each period in the current year: days, weeks, months and year. These are created correctly with one invalidation for the current year (2022).

After processing each period the core/CronArchive::repairInvalidationsIfNeeded method is run to make sure any higher level invalidations exist (eg. if a week was just updated then make sure the higher level month and year are invalidated as those figures will have changed)

This doesn't cause any problems for day periods as every processed day will be in the current year, months also never span years.

However if there is a week which spans the previous and current year (eg. Monday 2021-12-27 to Sunday 2022-01-02) then repairInvalidationIfNeeded will look for a year invalidation for 2021 (the week's start date year) and when it fails to find one it will replace the previously created 2022 year invalidation with a 2021 year invalidation.

This results in no archive for the current year and an unnecessary archive for the previous year.

This PR adds a simple check to skip any attempt to repair a year validation if the week spans more than one year, a similar check already exists for weeks that span two months. (#16886 (comment))

As repairInvalidationIfNeeded is part of the main archiving process this issue likely affects all archiving and is not specific to Custom Reports.

Ref L3-290
Also looks like it Fixes #18343

Review

@bx80 bx80 added the Bug For errors / faults / flaws / inconsistencies etc. label Jul 26, 2022
@bx80 bx80 added this to the 4.12.0 milestone Jul 26, 2022
@bx80 bx80 self-assigned this Jul 26, 2022
@justinvelluppillai
Copy link
Contributor

Nice find @bx80 and great description in the PR!

@bx80 bx80 added the Needs Review PRs that need a code review label Jul 26, 2022
@sgiehl
Copy link
Member

sgiehl commented Jul 27, 2022

@bx80 any chance for adding a useful test for that? If that doesn't work for core, we could at least add one in custom reports plugin, to ensure this doesn't regress later.

@sgiehl sgiehl removed the Needs Review PRs that need a code review label Jul 29, 2022
@bx80 bx80 added the Needs Review PRs that need a code review label Aug 8, 2022
@sgiehl sgiehl merged commit 1ef548f into 4.x-dev Aug 8, 2022
@sgiehl sgiehl deleted the l3-290-custom-report-invalidation branch August 8, 2022 15:16
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. Needs Review PRs that need a code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix for current year not processed for new custom repors
3 participants