Classify Transport Failure

• NATS: no responders (a 503 with no body).
• The pattern language: Retry depends on the distinction.

A request can fail in ways that look alike from a distance and are not alike: the responder did not answer in time, the responder does not exist, the server refused the request, or the responder answered with a failure of its own.

Which of several unlike failures has occurred, so that the caller can do the right thing about each?

• A timeout means someone is there and is slow.
• No responders means nobody is there at all, and the server knows it at once.
• A refusal is an answer: the request was understood and rejected.
• A body carrying a failed outcome is also an answer, and the request was handled.
• Retrying all four the same way is wrong in at least two of them.

Branch on the signal, and keep the four apart:

try {
    const auto reply = session.authenticated_request(subject, payload, timeout);
    throw_if_refused(reply, subject);           // refused, not answered
    // ... decode the body; a failed outcome is the service's own answer.
} catch (const ores::nats::service::request_refused_error& e) {
    // Understood and rejected: act on the code (forbidden, bad_request, ...).
} catch (const ores::nats::service::nats_connect_error& e) {
    if (e.kind() == ores::nats::service::nats_error_kind::services_unavailable) {
        // Nobody is listening: the service is down or the subject is wrong.
    }
} catch (const std::runtime_error& e) {
    // Everything else, including a request that timed out.
}

The four outcomes, and what each licenses:

The distinction is preserved by keeping the transport's signals distinct all the way out: the refusal is its own exception type, and no-responders carries a kind, so neither is flattened into "the request failed".

• One catch for everything. A refused request is retried as though the service were down.
• Retrying a refusal. The credential, permission or payload is still wrong.
• Treating no responders as a timeout. The caller waits out a deadline to learn what the first round trip already said, then retries in a tight loop.
• Decoding an empty refusal body. It reports a malformed payload for what is really an authorization failure.

Benefits

The caller's reaction matches the fault, and an operational fault is legible in the log as its own thing.

Liabilities

Every caller must handle four cases rather than one.

`request_sync` throws `nats_connect_error` with `nats_error_kind::services_unavailable` for no responders and a distinct runtime error for a timeout; `throw_if_refused` raises `request_refused_error` for a refusal and deliberately excludes the two session-expiry codes, which have their own handling.

• Bounded Request — the deadline this pattern interprets.
• Report a Refusal Off the Body — the producer of the refusal signal.

• NATS documentation, Request-Reply Resilience — the two failures and why they differ.
• NATS documentation, Request-Reply — the `_INBOX` mechanism and the no-responders signal.

• NATS service patterns — the structure note that orders this pattern language, and where to read this page in it.