Auto discovered UIs deadlock when discovery depends on the config
Designing a settings UI that lists configurable entities (per-account routing, per-resource overrides) by enumerating what the system has seen rather than what is configured.
A settings page populated a per-account override list by querying SELECT DISTINCT account FROM messages. The platform default was set to drop, which acks events at ingest but writes nothing to messages. As a consequence the per-account row that the user wanted to override the drop with never appeared in the UI — to surface the account they needed events to land, to land events they needed to change the routing, to change the routing they needed the account to surface. A circular dependency built into the UIs definition of what exists. The bug only appears when the platform default itself is what the user wants to deviate from. The fix is to enumerate from the source of intent (a list of running sync agents, a registry table, an explicit config of accounts to track) rather than from a side effect of intent (rows that survived the side effect). Side effect enumeration always deadlocks the case where the user wants to deviate from the default that suppressed the side effect.
When building a per-thing override UI ask which sources will populate the list. If the only source is a side effect of the current configuration, also pull from a source-of-intent table (agents registered, ports configured, accounts authenticated) so the user can override defaults that suppress the side effect.