Follow-up

Polling used to happen inside a request, which meant an authorization was chased only while somebody happened to be looking at it. A payer taking four days would never be chased at all.

#Six properties, none optional

Durable

A job that vanishes on restart is an authorization nobody is chasing.

Leased

Two workers running the same job means two payer calls, and there is no idempotency key upstream.

Fair

One practice with a thousand pending authorizations must not starve another with three. Capped per practice per tick.

Backed off

Intervals matched to what payers actually do, with jitter so a fleet of practices does not arrive at one payer in lockstep.

Escalating

As the CMS decision window closes the interval tightens, because that is when a decision is most likely and when missing one is most expensive.

Terminal

A job that exhausts its attempts becomes a human task. Nothing is dropped.

#The cadence

15m · 30m · 1h · 2h · 4h · 8h · 12h · 24h · 24h · 48h

Deliberately not a constant interval. Payers rarely answer in the first hour and rarely change after a week, so polling hard early and slowly later finds decisions sooner and wastes fewer calls.

#Window escalation

An expedited request divides the interval by three with a five-minute floor. See CMS obligations for the windows themselves and which payers they bind.

#The scheduler needs to see every tenant

Per-practice fairness requires comparing queues across practices, so the scheduler genuinely needs cross-tenant visibility. Row-level security refused the unscoped read an earlier version made silently - which is the point. The need is real, so it is declared and audited rather than assumed.

const acrossTenants = store.crossTenant(
  "scheduler dispatch: per-practice fairness requires seeing every tenant's queue",
);