Azure is the only zero-data-retention route for the gpt-5.6 family, so
its capacity 429s arrive frequently and OpenRouter forwards them inside
an HTTP 200 envelope. Those bypassed the rate controller entirely: a
paced run kept sending a request every three seconds into a throttled
endpoint, failing row by row. An in-envelope 429 now records the same
escalating cooldown as a transport 429, so later acquisitions fail fast
until the deadline passes.
Two of three banks were only pacing us, yet the dashboard demanded attention,
printed four nested wrappers and a nanosecond UTC deadline, and the scheduler
retried hourly into a refusal whose end time the bank had already given.
A rate limit now carries its retry time as data: Status.SyncRetryAt is set when
every failure is self-clearing, the connection reports rate_limited with that
deadline, the dashboard says synchronization resumes by itself and renders the
time in the browser's zone, and the scheduler sleeps until the deadline instead
of spending hourly session checks. Sync now still tries immediately.
The third bank's "transaction retrieval failed" hid its cause. Provider
failures Finance Duck determines itself are typed as banking.ProviderError,
so an unreachable provider, a timeout or an unusable response, such as a booked
transaction without a booking date, is reported instead of the opaque fallback.
Provider response text still never reaches the message.
Lars Nolden