fix/weekly cache metrics endpoint by alanpeixinho · Pull Request #1942 · kernelci/dashboard

alanpeixinho · 2026-06-17T22:06:01Z

What it is

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

Keep parity with email
Avoid slow endpoint calls

How to test:

Test warming cache crontab

First install the crontabs via poetry run python3 manage.py crontab add
Make sure they are installed poetry run python3 manage.py crontab show
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.
Verify the function that queries and stores on redis runs properly.
Verify redis now has updated cache on the keys (metricsTotalObjects, metricsBuildIncidents, metricsNewBuildIncidents, metricsLabSummary) (via redis-cli) or via python script.
Remember to remove the crontab from your system poetry run python3 manage.py crontab remove

Testing endpoint

Go to the metrics page
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".
Make sure subsequent access are cached.

Closes #1940

feat: add checkout selectors on hardware page (feat: add checkout selectors on hardware page #1904)
feat: dynamic metrics page (feat: dynamic metrics page #1920)
refactor: unversion tree and hardware listing flows (refactor: Unversion pages/endpoints for tree/hardware listing #1923)
feat: increase metrics cache time (feat: increase metrics cache time #1934)
Add githooks to manage commit DCO sign-off (Add githooks to manage commit DCO sign-off #1932)
Reports regzbot tracking (Reports regzbot tracking #1925)
fix: Include aggregate tables on snapshot/restore update_db commands (fix: Include aggregate tables on snapshot/restore update_db commands #1936)
fix(metrics): stabilize query cache and add weekly warm cron

bhcopeland · 2026-06-18T08:26:19Z

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


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).

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.

mentonin

Added some comments. I think this works in general, but should be seen as a palliative solution. A better solution might be a rollup table. I think we could also use a set of prometheus metrics (we are tracking difference between timestamps of time series with low cardinality).

mentonin · 2026-06-22T20:53:15Z

-        (SELECT COUNT(*) FROM checkouts WHERE _timestamp BETWEEN
-            NOW() - INTERVAL %(start_days_ago)s
-            AND NOW() - INTERVAL %(end_days_ago)s)
+        (SELECT COUNT(*) FROM checkouts WHERE _timestamp >=


I believe you can merge this SELECT with the previous one for (minor) performance gains

mentonin · 2026-06-23T00:02:33Z

+from django.utils import timezone as django_timezone
+
+
+def seeded_timestamp(*, days_ago: int = 1) -> datetime:


It would be great if we could include some specific tests related to the timestamp: out-of-order rows, cases before/after query intervals, check open or closed interval boundaries, etc.

GH won't let me mark this as resolved, but tests are looking very robust now 👍🏼

mentonin · 2026-06-23T00:31:11Z

+  const today = new Date();
+  const weekEndDaysAgo = (today.getUTCDay() + 1) % DAYS_IN_WEEK;
+  const endDaysAgo = Math.max(weekEndDaysAgo - 1, 0);
+  const startDaysAgo = endDaysAgo + activeDays + (weekEndDaysAgo > 0 ? 1 : 0);


IIUC this gets an interval of activeDays + 1 complete days (e.g. it includes 2 Fridays instead of 1 when activeDays=7)

On a broader note, I don't like the interface here. /metrics?i=n returns metrics from n days before the last Saturday, which is not really intuitive. I think you can only set i=7 or i=14 from the UI, but then why do we expose that as an integer for the user to edit?

Nice catch, I changed the backend behaviour and forgot to update here at some point.

On the topic of the url query param, I think I am with you.
I am removing this parameter altogether, unless users actually show need to share specific ranges via url. And even if they do, we might limit the options.

mentonin · 2026-06-23T00:40:30Z

      'This is the legacy version of the {page}, please refer to the new, optimized version {newPageLink}. If you find any bugs or divergences, please report to {gitHubLink}.',
+    'metricsPage.computedAt': 'Computed {computedAt}',
+    'metricsPage.period.previousTwoWeeks': 'Previous 2 weeks',
+    'metricsPage.period.previousWeek': 'Previous week',


Suggested change

'metricsPage.period.previousWeek': 'Previous week',

'metricsPage.period.previousWeek': 'Last week',

mentonin · 2026-06-23T21:47:23Z

+            <p>
+              {formatMessage(
+                { id: 'metricsPage.computedAt' },
+                { computedAt: formatDate(data.created_at, false, true) },


Should we display "Created at" or the actual interval spanned by the data?

In this case I really want to show the time data was computed, mostly because it is a long cache.
We could also show the range of the last week, but I am not sure if we gain much from doing it.

Wince we are slicing by _timestamp, I don't think the computed time is useful: the metrics for a specific time interval (in the past) should be constant

Fair. I am removing, since it was introducing unecessary complexity

mentonin · 2026-06-23T21:54:32Z

+# UTC midnight, so each lands exactly on an interval_params day boundary. This lets
+# adjacent metrics windows return distinct, non-zero counts to exercise the half-open
+# [start, end) boundaries on both sides.
+SEED_DAY_SPAN = 8


IIUC, this creates data at 00:00:00 at current day up to 7 days ago. The default query fetches events from 7 days ago, 00:00:00 up to yesterday, 23:59:59. So this does not test start date

Good point. I have moved the span further, not only to include prev responses, but also to help the test be more robust, and fail if we do not properly filter start date.

mentonin · 2026-06-23T21:55:31Z

+from django.utils import timezone as django_timezone
+
+
+def seeded_timestamp(*, days_ago: int = 1) -> datetime:


GH won't let me mark this as resolved, but tests are looking very robust now 👍🏼

mentonin · 2026-06-23T21:56:42Z

+    "n_tests": 26,
+    "n_issues": 17,
+    "n_incidents": 7,
    "prev_n_trees": 0,


previous values should probably also be seeded and tested for

mentonin · 2026-06-23T21:58:54Z

    'messages.olderPageVersion':
      'This is the legacy version of the {page}, please refer to the new, optimized version {newPageLink}. If you find any bugs or divergences, please report to {gitHubLink}.',
+    'metricsPage.computedAt': 'Computed {computedAt}',
+    'metricsPage.period.previousTwoWeeks': 'Previous 2 weeks',


Suggested change

'metricsPage.period.previousTwoWeeks': 'Previous 2 weeks',

'metricsPage.period.previousTwoWeeks': 'Last 2 weeks',

For consistency, since you accepted my suggestion

* 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. * Change seeds to include older timestamp Closes kernelci#1940 Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>

bhcopeland reviewed Jun 18, 2026

View reviewed changes

alanpeixinho force-pushed the fix/weekly-cache-metrics-endpoint branch 3 times, most recently from 2ed607d to 98b56ae Compare June 22, 2026 11:32

mentonin reviewed Jun 23, 2026

View reviewed changes

alanpeixinho force-pushed the fix/weekly-cache-metrics-endpoint branch from 98b56ae to 4b6cdd5 Compare June 23, 2026 19:40

alanpeixinho requested review from bhcopeland and mentonin June 23, 2026 20:59

mentonin reviewed Jun 23, 2026

View reviewed changes

alanpeixinho force-pushed the fix/weekly-cache-metrics-endpoint branch 2 times, most recently from 917fb5f to 7bed5fe Compare June 24, 2026 18:13

alanpeixinho requested a review from mentonin June 24, 2026 18:24

mentonin approved these changes Jun 24, 2026

View reviewed changes

alanpeixinho force-pushed the fix/weekly-cache-metrics-endpoint branch from 7bed5fe to 9ab53c0 Compare June 24, 2026 21:10

alanpeixinho added this pull request to the merge queue Jun 24, 2026

Merged via the queue into kernelci:main with commit 5ef7b2b Jun 24, 2026
7 checks passed

		from django.utils import timezone as django_timezone


		def seeded_timestamp(*, days_ago: int = 1) -> datetime:

	'metricsPage.period.previousWeek': 'Previous week',
	'metricsPage.period.previousWeek': 'Last week',

	'metricsPage.period.previousTwoWeeks': 'Previous 2 weeks',
	'metricsPage.period.previousTwoWeeks': 'Last 2 weeks',

Uh oh!

Conversation

alanpeixinho commented Jun 17, 2026

What it is

How to test:

Test warming cache crontab

Testing endpoint

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mentonin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants