`DirectoryApiClient` upstream timeout — a graceful-degrade fix was already rejected in review, and the failure keeps growing unaddressed

What is failing. App\Directory\DirectoryApiClient::fetch() calls cities-api.app.production.aws.selectra.io with no rescue()/try-catch around the HTTP call. A connection timeout throws ConnectionException before a Response exists, so it escapes uncaught and 500s every directory page on every site that uses this shared client. Two shortIds, same file, same root cause, different sites:

Why this is a decision, not a routine fix. A fix already shipped once — rescue(fn () => ..., null), reporting to Sentry by default, exactly the shape memory/review-feedback.md says is normally acceptable — and a human reviewer (@aurian) reverted it anyway: "hiding the upstream timeout behind a clean null degrade removes the only signal that cities-api is failing. Leaving this unhandled so it surfaces (Sentry / 500) is the correct behavior here." (PR #8898, 2026-07-14). That is a considered call that a 500 is the intended signal for this specific client, not an oversight — so a triage run cannot apply the review-feedback rule's normal "rescue() that still reports is fine" reading here; it was tried and explicitly rejected for this call site.

Why it is coming to you now instead of staying a REPORT row. This has been re-classified REPORT at every triage since 2026-07-02 (five runs) with no design proposed and no GitHub issue opened — the event count has grown 3.7x in that time (241 → 883) with nothing to show a human ever saw it outside a journal entry that scrolls away. That is precisely the failure this register exists to stop.

What is being asked. Whether cities-api going down should keep 500ing directory pages indefinitely (current behavior, deliberately preserved by the revert), or whether there is an acceptable middle design — e.g. a distinct "upstream degraded" response/status that is visibly different from a normal 200 (so it can't be mistaken for "working") but doesn't crash the request, or an uptime/alerting hook outside Sentry-issue-count that would let a graceful fallback stay actionable. Sizing that trade-off is exactly the human judgment call PR #8898 asked for and never got a follow-up design for.

Resolved