Why Your Agent's Channel List Fails Safely, Not Silently
With fifteen channel adapters and most of them unconfigured on any given deployment, one being down is the normal case — and the Channels page in Settings is built around that reality, not around it.
A page that depends on fifteen separate backend services has fifteen separate ways to have a bad day. The interesting design question isn't whether one of them will be unavailable at some point — with fifteen adapters, most unconfigured on any given deployment, that's not an edge case, it's closer to the normal state. The real question is what the page does about it.
One worker per channel, on purpose
Each of the fifteen channel adapters — Slack, Discord, Telegram, and the rest — runs as its own independent service, deliberately kept separate from the others. That isolation has a specific payoff: if one adapter is misbehaving, misconfigured, or simply not set up on a given deployment, the blast radius is exactly that one channel. It doesn't take the others down with it.
What actually happens when Settings pulls your channel list
Fetching "your linked channels" means asking all fifteen adapters at once, in parallel. If one of them fails to respond or returns an error, that specific channel comes back in the combined list with an error noted on its own row — items and identities from every other adapter that responded normally still show up completely unaffected. The page doesn't wait for every adapter to succeed before showing you anything, and it doesn't treat one failure as reason to show nothing.
Why "fail loud on the one, quiet on the rest" is the right default here
The alternative — a page that goes blank or shows an error banner because one of fifteen dependencies is unavailable — actively misrepresents the other fourteen. It tells you nothing works when in fact fourteen things work fine and one doesn't. That's a worse experience than showing you exactly which channel has a problem while leaving the rest usable, and it's a common failure pattern worth naming: a page that fails as a whole because one dependency failed is lying about everything else on it, even if the lie is unintentional.
Partial-outage handling like this is a recurring theme across reliability writing generally — "one dependency being down shouldn't blank the whole page" is close to a universal principle. What's worth pointing out here is that it's a deliberate, specific design choice on this page, not an accident of how the requests happen to be wired up.