rcourtman 8fff04eac5 fix(ai): query capacity forecast history under metrics-target ID not canonical ID ...

The deterministic capacity forecast queried utilization history using the
canonical resource ID (storage-<hash>), but the monitoring layer records
metrics under the metrics-target/source ID (MetricsTarget.ResourceID). For
most storage sources these two IDs diverge, so the forecast query always
found nothing and the feature stayed dormant even for pools with full
ingestion history (Proxmox, TrueNAS, PBS, agent-backed storage).

This splits the two ID roles in the precompute path: a new metricsID field
on patrolStoragePoolRow / patrolPrecomputeStorageSource carries the
metrics-target ID (resolved from SourceID() in the readState branch, or
MetricsTarget.ResourceID in the unified-resource branch) for history
queries, while the canonical id is still used for stamp-matching findings.

Adds a test proving the forecast fires when history exists only under the
metrics-target ID and that the resulting forecast resourceID stays
canonical so StampCapacityForecasts can still match it.

Contract (ai-runtime): the forecast must query history under the
metrics-target ID (StoragePoolView.SourceID()), not the canonical ID; the
forecast's own resourceID stays canonical for stamp-matching.

Refs lane: protection-posture-attention-queue

2026-06-27 22:18:09 +01:00

..

internal

Clear v6 prerelease-to-GA promotion gate

2026-04-20 16:33:03 +01:00

v6

fix(ai): query capacity forecast history under metrics-target ID not canonical ID

2026-06-27 22:18:09 +01:00

control_plane.json

Capture continuous discovery reconciliation

2026-05-28 16:42:01 +01:00

control_plane.schema.json

Map legacy stable releases in control plane

2026-04-11 13:23:07 +01:00