From 574b4dd35005cf395ad7359db9a93353ae5b7093 Mon Sep 17 00:00:00 2001 From: rcourtman <8825017+rcourtman@users.noreply.github.com> Date: Mon, 5 Oct 2026 17:48:05 +0100 Subject: [PATCH] Name mock history seeding as the observed slow tenant stop The deletion-budget note and its test said only that a loop still starting up can be slow to stop. The CI failures have a specific cause: in mock mode Monitor.Start runs startMockMetricsSampler synchronously before its select loop, and prepareMockMetricsHistory seeds seven days of fixture history without a context, so the loop saw its cancelled context only once seeding finished ("Mock metrics history sampler started" and "monitoring loop stopped" log in the same second in runs 37329726585 and 37331626618). Say so in the contract and the test comment. --- .../release-control/v6/internal/subsystems/monitoring.md | 9 ++++++--- internal/monitoring/monitor_additional_test.go | 8 +++++--- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/docs/release-control/v6/internal/subsystems/monitoring.md b/docs/release-control/v6/internal/subsystems/monitoring.md index c0ac04025a..5e249dedf6 100644 --- a/docs/release-control/v6/internal/subsystems/monitoring.md +++ b/docs/release-control/v6/internal/subsystems/monitoring.md @@ -1408,9 +1408,12 @@ for the tenant monitoring loop to exit before it refuses with `tenant_shutdown_incomplete` and keeps the data. Process shutdown and `RemoveTenant` keep the two-second `tenantMonitorShutdownTimeout`. Deletion gates the data on that wait, so the budget must cover a loop that is still -starting up or finishing a tick: under CI load a just-used organization's loop -took 8-10 seconds to see its cancelled context, and the two-second budget turned -an ordinary delete into a refusal. A loop that never exits still refuses. +starting up or finishing a tick. The observed case is mock mode: +`Monitor.Start` runs `startMockMetricsSampler` synchronously before its select +loop, and `prepareMockMetricsHistory` seeds seven days of fixture history +without a context, so a just-used organization's loop took 8-10 seconds under CI +load to see its cancelled context and the two-second budget turned an ordinary +delete into a refusal. A loop that never exits still refuses. Proxmox physical-disk polling is also a continuity boundary. A failed or permission-denied `disks/list` call must remain an error so the monitor can use linked host-agent inventory or retain same-instance, same-node prior evidence; diff --git a/internal/monitoring/monitor_additional_test.go b/internal/monitoring/monitor_additional_test.go index eaaa70230a..bc771e5d42 100644 --- a/internal/monitoring/monitor_additional_test.go +++ b/internal/monitoring/monitor_additional_test.go @@ -1115,9 +1115,11 @@ func shortenTenantShutdownBudgets(t *testing.T, plain, deletion time.Duration) { } // A tenant monitor that is still starting up or finishing a tick can take -// longer than the plain shutdown budget to see its cancelled context. In CI a -// just-used organization's loop took 8-10s, so deletion refused with -// tenant_shutdown_incomplete. Deletion waits on its own, longer budget instead. +// longer than the plain shutdown budget to see its cancelled context. In CI's +// mock mode, Start seeds mock metrics history synchronously before its select +// loop, so a just-used organization's loop took 8-10s to stop and deletion +// refused with tenant_shutdown_incomplete. Deletion waits on its own, longer +// budget instead. func TestTenantDeletionWaitsForSlowMonitoringLoop(t *testing.T) { shortenTenantShutdownBudgets(t, 50*time.Millisecond, 2*time.Second)