Summary
The self-host Orb's periodic relay-drain (orb-relay-drain, runs every 30s in pull mode) is timing out. Sentry shows a TimeoutError: The operation was aborted due to timeout recurring since 2026-07-15, still ongoing (13+ occurrences, most recent within the last day).
The drain calls POST /v1/orb/relay/pull, whose handler (pullRelayPending) unconditionally runs pruneRelayPending first on every call. That function issues a SELECT and a DELETE against orb_relay_pending filtered only by created_at:
SELECT ... FROM orb_relay_pending WHERE created_at < ... ORDER BY created_at, delivery_id LIMIT 20
DELETE FROM orb_relay_pending WHERE created_at < ...
Both existing indexes on that table lead with installation_id, so neither serves a bare created_at predicate — both queries are full table scans, run fleet-wide, every 30 seconds per self-host instance, against the AbortSignal.timeout(30_000) budget of the pull request itself.
Area
REST API
Expected behavior
The drain's pruneRelayPending call should complete well within the 30s pull-request timeout, using an index range scan.
Actual behavior
pruneRelayPending's SELECT and DELETE full-scan orb_relay_pending, occasionally exceeding the 30s budget and aborting the whole pull request with a TimeoutError. Errors are captured (not swallowed) via both the Sentry cron monitor and a direct captureError call, so this fires on every occurrence.
Reproduction
Not easily reproducible without a fleet-scale orb_relay_pending table; confirmed via Sentry event volume and by reading the query plan implied by the existing index definitions vs. the query predicate.
Validation
Confirmed both existing indexes on orb_relay_pending lead with installation_id, not created_at, so a created_at-only predicate can't use either.
Public-safety check
Summary
The self-host Orb's periodic relay-drain (
orb-relay-drain, runs every 30s in pull mode) is timing out. Sentry shows aTimeoutError: The operation was aborted due to timeoutrecurring since 2026-07-15, still ongoing (13+ occurrences, most recent within the last day).The drain calls
POST /v1/orb/relay/pull, whose handler (pullRelayPending) unconditionally runspruneRelayPendingfirst on every call. That function issues a SELECT and a DELETE againstorb_relay_pendingfiltered only bycreated_at:Both existing indexes on that table lead with
installation_id, so neither serves a barecreated_atpredicate — both queries are full table scans, run fleet-wide, every 30 seconds per self-host instance, against the AbortSignal.timeout(30_000) budget of the pull request itself.Area
REST API
Expected behavior
The drain's
pruneRelayPendingcall should complete well within the 30s pull-request timeout, using an index range scan.Actual behavior
pruneRelayPending's SELECT and DELETE full-scanorb_relay_pending, occasionally exceeding the 30s budget and aborting the whole pull request with aTimeoutError. Errors are captured (not swallowed) via both the Sentry cron monitor and a directcaptureErrorcall, so this fires on every occurrence.Reproduction
Not easily reproducible without a fleet-scale
orb_relay_pendingtable; confirmed via Sentry event volume and by reading the query plan implied by the existing index definitions vs. the query predicate.Validation
Confirmed both existing indexes on
orb_relay_pendinglead withinstallation_id, notcreated_at, so acreated_at-only predicate can't use either.Public-safety check