hermes - 💡(How to fix) Fix [Feature]: surface IPv6-related fallback latency in gateway runtime diagnostics

Problem or Use Case

Gateway responses, especially via Discord, can take tens of seconds before the agent starts responding.

Version observed:

v2026.5.16-1099-gad6aa9844

In my environment:

• The delay did not happen when using Hermes from the CUI or WebUI.
• The delay did happen via the Discord gateway.
• With help from Hermes, I added local logging and the delay appeared to occur around API calls made from the gateway path.
• After changing the host resolver behavior with gai.conf to avoid/prefer away from IPv6, the Discord gateway latency disappeared.

This suggests that, in some environments, IPv6-related DNS resolution or connection attempts may add significant latency before falling back to IPv4.

The main problem is discoverability. I noticed this because I also use the CUI/WebUI and could compare the behavior. Users who primarily use Discord or another gateway may not realize this is a network / IPv6 fallback issue. From their perspective, it simply looks like “Hermes is slow on Discord” or “the gateway is hanging”.

Hermes already has an option that may fix this in affected environments:

network: force_ipv4: true

However, this option is hard to discover because affected users are likely to search for Discord latency, gateway slowness, or slow responses rather than IPv6 settings.

Proposed Solution

Surface possible IPv6-related fallback latency from the gateway runtime itself, not only from manual troubleshooting.

For example:

• If the gateway observes unusually slow API calls before the agent starts responding, log a troubleshooting hint.
• The hint could mention that IPv6-related DNS / connection fallback latency may be involved.
• The hint could suggest trying:

network: force_ipv4: true

It would also be helpful for hermes doctor to include a related check, such as comparing IPv4 and IPv6 resolution / connection latency for the configured API provider endpoint.

This should probably also be mentioned in Discord gateway troubleshooting docs, since the visible symptom looks like Discord latency rather than a networking issue.

Alternatives Considered

A manual workaround is to change the host resolver behavior, for example with gai.conf, or to set:

network: force_ipv4: true

This fixes the issue in affected environments, but it requires the user to already suspect IPv6 fallback latency. That is unlikely for users who mainly interact with Hermes through Discord or another gateway.

Another option is to document this only under general “slow responses” troubleshooting, but runtime diagnostics would be more useful because the gateway can surface the hint when suspicious latency is actually observed.

Feature Type

Gateway / messaging improvement

Scope

Medium (few files, < 300 lines)

Contribution

I am not able to submit a PR myself.

I found and mitigated this with help from Hermes, but I do not have enough context to investigate or implement the fix in the codebase myself.

Debug Report

I cannot provide a debug report, but I can share the local observation summary above.