Files
member-console/internal/integration/queries/outbox.sql
T
cgalo5758 56a743fb32 Add overview counts and system-health queries
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.
2026-07-25 15:44:21 -05:00

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;