RELIABILITY BRIEF · P2 · PROVIDER / PERFORMANCE
Hermes Token Plan IPv6 Fallback Timeout: Issue #71215
A sourced reliability brief on an open report that an unreachable IPv6 listener can add a full TCP timeout before IPv4 fallback for Hermes Token Plan API calls on dual-stack hosts.
What the report says
The open issue reports that the Alibaba Cloud Token Plan endpoint publishes AAAA records pointing to an NLB instance whose IPv6 listener is unreachable. In the reported dual-stack environment, Python socket resolution attempts IPv6 first, waits for the TCP connection timeout, and then falls back to IPv4, adding an estimated 10 to 30 seconds to each API call.
Status boundary: This page summarizes a public, open issue report. It is not an independent reproduction, security assessment, product-wide reliability estimate, or confirmation that the report remains unresolved.
Operational significance
If reproduced, this can turn a provider connectivity path into repeated interactive latency for affected dual-stack hosts. This brief summarizes an open report only. It does not establish prevalence, provider-side root cause, behavior on every resolver or operating system, or an independently measured latency distribution.
Evidence-bounded verification checklist
| Check | Question | Safe evidence practice |
|---|---|---|
| Environment identity | Is the affected host dual-stack, and which resolver, runtime, and provider configuration are in use? | Record operating system, runtime, resolver policy, provider endpoint, and version context. |
| Address reachability | Can the endpoint be reached through the advertised IPv6 and IPv4 paths? | Capture bounded, non-sensitive connection diagnostics and distinguish DNS from listener reachability. |
| Timing pattern | Does the delay recur before IPv4 fallback on a representative request? | Measure repeated requests with the same conditions and preserve timeout configuration. |
| Scope control | Is the behavior isolated to Token Plan versus a broader host networking condition? | Compare only with clearly documented endpoints and avoid generalizing from one provider path. |
| Mitigation validation | Does an approved configuration or upstream change remove the observed delay? | Re-run the same bounded test and report residual uncertainty. |
Handling guidance
- Treat repeated provider connection timeouts as a reliability investigation, not proof of a product-wide regression.
- Preserve resolver output, timestamps, connection settings, and redacted logs so upstream maintainers can reproduce the path.
- Avoid changing network or DNS policy in production without an approved rollback plan and validation window.
- Track the upstream issue for reproduction requests, provider updates, and any documented workaround or fix.
Source evidence
Hermes Agent GitHub issue #71215
Issue status, labels, discussion, and remediation guidance can change. Consult the upstream report directly before making deployment or product decisions.