fix(integrations): suspend cron answers inside Cloudflare's origin timeout
Follow-up to #7947. The first production run at 23:00Z got HTTP 524 from Cloudflare at ~2m09s: api.superset.sh's origin timeout is ~100s, so a 240s run never answers in time. QStash retried three times and each retry started another run beside the ones still executing on Vercel — four overlapping passes over the same candidate lists, and the delivery ends in the DLQ every hour.
The run budget drops to 60s. Every processed row is already written and the schedule is hourly, so the backlog drains over a few runs (the first run suspended 1,411 installations and revoked 288 Linear connections before the cut-off).
Same constraint applies to any QStash job on api.superset.sh that runs longer than ~100s.
Summary by cubic
Fixes the suspend cron delivery failure on api.superset.sh by cutting the run budget from 240s to 60s. The first production run got HTTP 524 from Cloudflare at ~2m09s (origin timeout is ~100s), and QStash's three retries each started a fresh run alongside the still-running ones — up to four overlapping passes over the same candidate lists, ending in the DLQ every hour.
The 60s budget gets the summary out before Cloudflare gives up. Since every processed row is already written and the cron is hourly, the backlog drains over a few runs — the first run suspended 1,411 installations and revoked 288 Linear connections before the cutoff. Any other QStash job on api.superset.sh running longer than ~100s has the same constraint.
Summary by CodeRabbit
- Updates
- Suspension processing now runs within a shorter time window. Any remaining items are handled in subsequent runs.