Files
buzz/crates
Salman Mohammed 6847882b14 fix(relay): stop logging unmapped-host NIP-FI denials as server failures (#8997)
## What this does

In enforce mode, a request whose Host maps to no community gets NIP-FI's
`authorization_unavailable` 503 (`docs/nips/NIP-FI.md`, Rejection and
privacy table). tower-http's default classifier treats every 5xx as a
failure, so each of these requests also logs a
`tower_http::trace::on_failure` error. That line has no host or path,
only `503` and `latency: 0 ms`. When a scanner probes a host this relay
doesn't serve, it produces thousands of these lines in a minute, and
they trip error-rate alerts even though nothing is down.

This PR keeps the wire response the same and stops counting these
denials as server failures:

- `nip_fi_core::community_denial` builds the same `http_denial`
response. When the Host is confirmed unmapped, it adds an internal
`UnresolvedHost` response extension. Extensions never reach the wire, so
the NIP-FI denial contract ([FI-TRACE-DENIAL-ORACLE]) still holds.
- Each site that turns a community-resolution failure into a denial now
uses it:
  - the router guard (`nip_fi_assertion_guard`)
  - the WebSocket upgrade (`check_nip_fi_at_upgrade`)
  - HTTP admission, for routes the guard exempts (`Stage::Community`)
- The HTTP trace layer now uses `RelayResponseClassifier`. It treats
marked responses as expected and keeps tower-http's 5xx-is-failure rule
for everything else.

Other 503s still log as failures. That includes an unavailable JWKS key
source on a mapped host, `deny_protected`, a stale snapshot, and a
failed database lookup.

## Why not return 4xx for unmapped hosts?

NIP-FI.md maps "community/Host resolution unavailable" to 503, and
`nip_fi_enforce_unmapped_host_is_503_before_verification` pins that
ruling. Changing the status would be a spec change. This PR only changes
how the relay logs these denials.

## Database community source

With `BUZZ_NIP_FI_COMMUNITY_SOURCE=database`, a not-found host and a
failed lookup (DB error, timeout, shed waiter) return the same denial
class. The marker is set only when the host is confirmed unmapped: a
missing Host, a non-bindable host, or a live negative-cache entry.
Resolver outages stay unmarked and still log as failures. With the `env`
source, every resolution failure means the host is unmapped, so it is
always marked.

## Testing

- `nip_fi_enforce_unmapped_host_is_503_before_verification` (guard, root
upgrade, audio upgrade) and
`enforce_unmapped_host_is_503_before_nip98_and_verifier` (HTTP
admission) now also assert the marker. Mutation check: removing the
guard marker turns the router test red.
- New `nip_fi_mapped_host_dependency_503_is_not_marked_unresolved`: a
mapped-host 503 from an unavailable key source is unmarked and still
classified as a failure.
- New `relay_response_classifier_skips_only_unresolved_host_denials`:
covers marked 503, unmarked 503, 500, 200 and 401.
- New `only_confirmed_unmapped_hosts_are_marked_as_expected_denials`
(database source, all three sites): a negative-cached host and a
non-bindable host are marked; a bound host whose lookup fails is not.
Mutation check: marking every database failure turns it red.
- `cargo clippy -p buzz-relay --all-targets -D warnings` is clean, and
the pre-push `rust-tests` lane passed.
- Local relay, before and after. Setup: enforce mode, `RUST_LOG=error`,
one mapped host, JWKS unreachable on purpose. Both builds got the same
requests:

| Request | Status (both builds) | `on_failure` errors before | after |
|---|---|---|---|
| Unmapped host, 4 protected paths | 503 | 4 | 0 |
| Unmapped host, WebSocket upgrade on `/` | 503 | 1 | 0 |
| Mapped host, no assertion | 401 | 0 | 0 |
| Mapped host, well-formed JWT, JWKS unreachable | 503 | 1 | 1 |
| Unmapped host, `/assets/` path and `POST /api/invites/claim` | 404 | 0
| 0 |

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: Salman Mohammed <smohammed@squareup.com>
Co-authored-by: opus <f038cc09b32a776e7d95b65c267e9d851777ee2b6cdbd46a48edba01b1d10ebd@buzz.block.builderlab.xyz>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-03 16:08:13 -05:00
..