Back the operator landing surface with live deployment counts and integration health signals, one sqlc query per owning module. CountDeliveringGrants joins core.pool_provisions rather than filtering grants.status: grants.status is an issuance ledger recording what was written down and whether it was later revoked, not whether service is flowing. The current-delivery fact lives on pool_provisions.status, and a grant can sit at status='active' with every provision ended. Counting the ledger alone would overstate delivery. CountClaimsByLifecycle and CountOutboxByStatus each return their buckets in a single row, so the halves that get printed together are read at the same instant and the landing surface pays one round trip rather than one per bucket.
21 lines
1.0 KiB
SQL
21 lines
1.0 KiB
SQL
-- name: CountOutboxByStatus :one
|
|
-- Operator overview "System" panel: the health of the integration delivery
|
|
-- queue in one round trip.
|
|
--
|
|
-- The three buckets mean different things to an operator and are therefore
|
|
-- reported separately rather than summed:
|
|
-- pending — enqueued, not yet attempted or waiting on next_attempt_at.
|
|
-- A steady non-zero value is normal.
|
|
-- failed — attempted and errored, still inside max_attempts, so the
|
|
-- poller will retry. In-flight, not lost.
|
|
-- dead_letter — exhausted its retries. Nothing will move this without an
|
|
-- operator, so it is the only bucket that warrants an alarm.
|
|
--
|
|
-- Enqueue-side writes go through integration.Enqueue (internal/integration/
|
|
-- outbox.go); this is a read-only health probe over the same table.
|
|
SELECT
|
|
COUNT(*) FILTER (WHERE status = 'pending') AS pending_count,
|
|
COUNT(*) FILTER (WHERE status = 'failed') AS failed_count,
|
|
COUNT(*) FILTER (WHERE status = 'dead_letter') AS dead_letter_count
|
|
FROM core.outbox;
|