Skip to content

fix/weekly cache metrics endpoint#1942

Open
alanpeixinho wants to merge 1 commit into
kernelci:mainfrom
profusion:fix/weekly-cache-metrics-endpoint
Open

fix/weekly cache metrics endpoint#1942
alanpeixinho wants to merge 1 commit into
kernelci:mainfrom
profusion:fix/weekly-cache-metrics-endpoint

Conversation

@alanpeixinho

Copy link
Copy Markdown
Contributor

What it is

Makes the metrics page cache its response for a week, so we can:

  1. Keep parity with email
  2. Avoid slow endpoint calls

How to test:

Test warming cache crontab

  1. First install the crontabs via poetry run python3 manage.py crontab add
  2. Make sure they are installed poetry run python3 manage.py crontab show
  3. You can execute the crontab via poetry run python3 manage.py crontab run <hash of cronjob>
    * It is important to point here that the warm is supposed to run at the same time as email metrics (saturday), so they might not be aligned to the same days as frontend requests.
    * Alternatively to this, we could change the system clock.
  4. Verify the function that queries and stores on redis runs properly.
  5. Verify redis now has updated cache on the keys (metricsTotalObjects, metricsBuildIncidents, metricsNewBuildIncidents, metricsLabSummary) (via redis-cli) or via python script.
  6. Remember to remove the crontab from your system poetry run python3 manage.py crontab remove

Testing endpoint

  1. Go to the metrics page
  2. Make sure it loads data from the range [lastSaturday - 7 days, lastSaturday] for the "previous week" and [lastSaturday - 14, lastSaturday] for the "2 previous weeks".
  3. Make sure subsequent access are cached.

Closes #1940

)
end_datetime = datetime.combine(
today - timedelta(days=end_days_ago),
time.max,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Trying to work out the SQL below, I think this will be an 8-day window? Because it causes SQL to be at the end of the 7-day window (i.e. on the last day it will be at midnight).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yes, you are correct.
The cached query is happening at the start of the day (just like the mail notification), so the 8th day would end up empty.
But still, it is not robust to rely on time of the call.

@alanpeixinho alanpeixinho force-pushed the fix/weekly-cache-metrics-endpoint branch from fa3d93c to a580d94 Compare June 18, 2026 19:39
  * Use fixed UTC date bounds for metrics intervals so cache keys stay stable across the week
  * Expose created_at on the API
  * Align the dashboard with the email window, and warm the cache after the Saturday metrics email.

  Closes kernelci#1940

Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>
@alanpeixinho alanpeixinho force-pushed the fix/weekly-cache-metrics-endpoint branch from a580d94 to 6230330 Compare June 18, 2026 20:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Weekly caching on metrics page

2 participants