pub fn is_retryable(code: &str) -> boolExpand description
Whether a Choir rejection code can succeed on an identical retry.
The listed codes are decisions about the request itself: a binding that conflicts, a signature that does not verify, a channel the key does not own. None of them change because time passed, so retrying is a scheduler burning attempts on a refusal that is already final.
Everything else, including an unrecognised code, is treated as transient. That asymmetry is deliberate. Calling a transient failure terminal strands work that would have succeeded, while calling a terminal one transient costs retries that fail fast and loudly. A code this build has never heard of is more likely a newer node than a new class of permanent refusal.