> Sentry's MCP token is still expired, so this came from the production
DB again.
## The bug
`EnableBankingSyncer::sync` loops a connection's accounts doing
transactions-then-balances. The transaction call was wrapped, but only
for `InaccessibleBankAccountException` and
`WrongTransactionsPeriodException`. A
`TransientBankingProviderException` — what EnableBanking's HTTP 400
`{"error":"ASPSP_ERROR"}` becomes, i.e. "the bank's connector failed" —
propagated out and abandoned the loop, so **every account behind the
failing one was skipped, along with its balance, cycle after cycle**.
Verified on a CaixaBank connection with three accounts:
| account | transactions | balance days | last balance |
|---|---|---|---|
| 1 | 618 | 231 | 2026-07-19 |
| 2 | 0 | 13 | **2026-06-12** |
| 3 | 0 | 13 | **2026-06-12** |
2026-06-12 is the connection's `last_synced_at` — the last time a run
completed. Account 1 kept importing for another five weeks; 2 and 3
never got another turn.
**That user has since deleted their account, so this ships as a latent
fix, not a rescue.** 84 of the 260 live EnableBanking connections have
two or more accounts.
## Two things I had wrong
I opened this from a different pair of connections and the product
review took both apart with data I hadn't gathered — request durations.
- **Openbank (4 accounts, 0/0 on two of them)**: I read it as
starvation. It fails in **567–1,358 ms**, less than a single account's
work (a healthy Openbank account is ~3.7s), so it is failing on the
*first* call. And all four live Openbank connections stopped syncing
within four minutes of each other on 2026-08-11 18:03–18:07. That is a
**bank-wide connector outage**, not a per-account fault. Its earlier
zero-attempt days were 429s on the daily PSU quota, at 10.7s / 14.4s /
20.7s in — a different failure this diff deliberately does not touch.
- **Renta 4 (0 transactions in 67 days)**: 62 of those days had **zero
attempts**, because the connection had dropped out of the scheduled
rotation — the bug #782 fixed. Genuine consecutive retries: five days.
The mechanism is real; my examples of it weren't. The CaixaBank
connection is.
## Deliberately conservative
The first version let a partial run report success. Both reviews pushed
back and they were right, so it no longer does — the failure is raised
once every account has had its turn. The connection keeps its Error
state, its retries and its unset `last_synced_at` exactly as today.
**The only thing that changes is that the accounts behind the failing
one get attempted at all.**
What recording it as a success would have cost, all verified in the
code:
- **An Active badge and a fresh "Last synced" over an account that had
stopped updating.** `manage-accounts.tsx:285` renders every synced
account as `Syncing`, hardcoded; there is no per-account sync state
anywhere in the product, and the new metadata key had no reader. That is
a quieter dead end than the one being fixed.
- **Permanent loss of the failing account's derived balance history.**
`calculateHistoricalBalances` is gated on the *connection's* first sync.
On a partial first run it no-ops for the failing account (no
transactions yet), and once `last_synced_at` is set it is never called
again — so when that account finally backfills a year, its daily
balances are never computed while its siblings have them.
- **A "618 new transactions" email.** Stamping
`bank_transactions_email_cutoff_at` on a partial first sync means the
failing account's eventual backfill all lands after the cutoff, which is
precisely what the cutoff exists to suppress.
- The failing account's in-cycle retries would have dropped from 3 to 1.
A provider that never answered is rethrown immediately rather than
tolerated: `statusCode` is null only on the `ConnectionException` path,
and carrying on there spends the client's 20s timeout per account
against the job's 120s. Prod: a 26-account connection already takes 62s
when everything works, and a 5-account one has peaked at 67s. Without
this guard the fix would have turned a provider timeout into a killed
job.
## Verification
`tests/Feature/OpenBanking`: 358 tests, 348 pass, and the **same 10
failures as clean main** (Inertia page-render tests hitting the SSR
`/render` endpoint, no local server). 4 new tests driven through the
existing `runSync()` helper so they assert the job-level outcome, each
verified to fail with only its own change reverted:
- the starvation case (remove the catch → fails),
- the unreachable-provider guard (remove it → fails),
- **a 429 still reaches the job** — the property I was most worried
about. 429s arrive as a raw `RequestException`, never as
`TransientBankingProviderException`, so the new catch cannot swallow one
and keep burning a per-consent daily quota account after account.
Confirmed against 30 days of prod logs: 821 rate-limit failures, every
one recorded as `RequestException`, zero as the wrapped type.
- and that a partial run still leaves the connection in Error with
`last_synced_at` untouched.
`pint`, `dry` and `crap` green — `sync` was already at complexity 13
before this and the new branches took it to 16, so `resolveWindow`,
`recordAccountTransactionFailure` and `syncBalances` are extracted and
it now sits under 10.
## Follow-ups, not done here
- **The real systemic problem is quota, not this.** 260 rate-limit
events across 26 connections and 24 users in 7 days. The default backoff
is one hour when the message doesn't say "daily", and the scheduler runs
every six — so the backoff expires long before the next cycle and
changes nothing. Trade Republic connections 429 on every single cycle,
which is why 11 users have transactions but no balance at all. That
wants a design, not a patch, and it is the biggest thing in this
subsystem.
- **No per-account sync state.** Until that exists, a connection can
only be all-good or all-bad, which is what forced the conservative
choice above.
- **No escalation for a connection that never succeeds.** Since #757
correctly stopped counting transient failures, "The bank provider is
temporarily unavailable. We will try syncing again later." is a
permanent state with no threshold, no copy change and no email.
- **`WrongTransactionsPeriodException` still skips the balance call.**
The bank refused a date range; `/balances` takes none. Same argument as
this fix, one line, left out to keep the diff to one behaviour.
- **`WiseSyncer`'s transaction call is still unwrapped** — the same bug
class in the file #788 touched. Lower stakes (one token, one host) but
worth closing.
## Auto-merge
Enabled. The behaviour change is a single `catch` that lets the loop
finish, with every other observable — status, timestamp, retries,
notifications, first-sync side effects — deliberately identical to
today. It is additive for the accounts that were being skipped and a
no-op for single-account connections, which are 7,980 of the ~12,500
runs in the last 14 days.
Víctor Falcón