fix(rc-entitlement-drift-check): extend cron pg_net timeout to 60s

[Patchalv]

Observability follow-up to #60 / #66 / #68.

Summary

The drift check function takes ~30 seconds with the current profile count because per-customer RC fetches are sequential, but the cron migration's `net.http_post` call uses pg_net's default 5-second timeout. The function ran to completion on every fire (Sentry events, heartbeat logs all worked) but `net._http_response.status_code` was always recorded as `NULL` for cron-triggered runs, making the cron's success state invisible from SQL.

This migration uses `cron.alter_job` to replace just the command text on the existing scheduled job, keeping the schedule, jobid, and lock-table behavior identical. Function behavior is unchanged.

How this surfaced

During the first real smoke test of #68:

• `request_id 37` (default 5s timeout): `status_code: null` — pg_net gave up, function still ran.
• `request_id 38` (explicit 60s timeout): `status_code: 200, content: '{"drift_count":0}'` — pg_net captured the actual response.

The fix is to make cron behave like request 38.

Test plan

After merging:

• `git pull && supabase db push`

• In the SQL editor, confirm the cron command was updated:

  \`\`\`sql
  select jobname, schedule, command from cron.job
  where jobname = 'rc-entitlement-drift-check';
  \`\`\`
  
  Command should now include \`timeout_milliseconds := 60000\`.
  

• Wait for the next `:17 mod 6h` UTC scheduled fire, then check:

  \`\`\`sql
  select id, status_code, content, created from net._http_response
  order by created desc limit 3;
  \`\`\`
  
  The row from the cron fire should show \`status_code: 200\` and \`content: '{\"drift_count\":N}'\`. Previously these rows showed \`status_code: null\`.
  

Follow-up

None.

[coderabbitai]

Warning

Rate limit exceeded

@Patchalv has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 22 minutes and 1 second before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 100ce968-086a-45f0-9098-b286c4eaafcb

📥 Commits

Reviewing files that changed from the base of the PR and between c09a826 and f60147b.

📒 Files selected for processing (1)

• supabase/migrations/20260513000003_extend_drift_check_pg_net_timeout.sql

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}