Skip to content

fix(model_metadata): add HERMES_DISABLE_MODEL_METADATA and tighter timeout - #46685

Closed
vanthinh6886 wants to merge 1 commit into
NousResearch:mainfrom
vanthinh6886:fix/gateway-metadata-timeout
Closed

fix(model_metadata): add HERMES_DISABLE_MODEL_METADATA and tighter timeout#46685
vanthinh6886 wants to merge 1 commit into
NousResearch:mainfrom
vanthinh6886:fix/gateway-metadata-timeout

Conversation

@vanthinh6886

Copy link
Copy Markdown
Contributor

Fixes #46620

Problem

fetch_model_metadata() uses timeout=10 (single int) which sets both connect and read timeout to 10s. Through a corporate HTTP proxy that returns 403 on CONNECT to openrouter.ai, urllib3 can retry/block for 7+ minutes, preventing the gateway from reaching start_polling.

Changes

  1. HERMES_DISABLE_MODEL_METADATA env var — allows completely skipping the OpenRouter metadata fetch. Useful for air-gapped/proxied deployments where openrouter.ai is unreachable. Returns cached data (memory or disk) if available, otherwise empty dict.

  2. Tuple timeout (5, 10) — 5s connect timeout, 10s read timeout. Fails fast when the endpoint is unreachable through a proxy, instead of allowing urllib3 to block for the full 10s per retry stage.

Testing

  • Set HERMES_DISABLE_MODEL_METADATA=1 and verify gateway starts without hanging
  • With metadata enabled, verify connect timeout is 5s (not 10s)
  • Verify normal OpenRouter metadata fetch still works when endpoint is reachable

…meout

Gate fetch_model_metadata() behind HERMES_DISABLE_MODEL_METADATA env var
so air-gapped/proxied deployments can skip the OpenRouter fetch entirely.
Also change timeout=10 to timeout=(5, 10) to fail fast on connect when
the endpoint is unreachable through a proxy.

Fixes NousResearch#46620
@alt-glitch alt-glitch added type/bug Something isn't working comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint provider/openrouter OpenRouter aggregator area/config Config system, migrations, profiles P1 High — major feature broken, no workaround labels Jun 15, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related: fix PR for #46620.

@liuhao1024

Copy link
Copy Markdown
Contributor

Verified. Clean and well-scoped:

  • Env var guard: HERMES_DISABLE_MODEL_METADATA checked at the top of fetch_model_metadata(). Returns in-memory cache → disk cache → empty dict (graceful degradation).
  • Timeout tuple: (connect=5s, read=10) replaces the flat timeout=10. This fails fast on unreachable endpoints (proxy CONNECT failures) while still allowing slow reads.
  • No regressions: The disk cache fallback path (_load_model_metadata_disk_cache) was already present; the env var check just short-circuits the HTTP fetch.
  • Docstring: The inline comment correctly explains the air-gapped/proxy use case.

No issues found.

@teknium1 teknium1 added sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jun 21, 2026
@teknium1

teknium1 commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Thanks for the fix, @vanthinh6886 — and for the accurate diagnosis of the startup-hang root cause.

Closing as already fixed on main, via the same route the underlying issue (#46620) was resolved:

  • The startup OpenRouter metadata fetch now runs in a daemon background thread (agent/agent_init.py:412), so it can never gate the gateway reaching start_polling.
  • It's provider-gated on provider == "openrouter" or _is_openrouter_url(), so a LiteLLM / non-OpenRouter deployment (like the reporter's) never issues the request at all.

Together that eliminates the 7-minute proxy hang without needing to disable anything.

On the two changes here specifically:

  1. HERMES_DISABLE_MODEL_METADATA — we keep .env for secrets only; non-secret behavioral flags go in config.yaml. And its intent (skip the fetch when the endpoint is unreachable / not OpenRouter) is already covered by the provider gate above.
  2. Tuple timeout (5, 10) — reasonable in isolation, but the ~7 min wasn't the 10s timeout; it was urllib3 retry/backoff through the proxy, which a tuple timeout doesn't shorten. And now that the fetch is backgrounded, its duration no longer touches startup.

If you can still reproduce a startup hang on current main, please reopen with fresh repro steps against the latest version. Appreciate the contribution.

@teknium1 teknium1 closed this Jul 1, 2026
kshitijk4poor pushed a commit that referenced this pull request Jul 9, 2026
… on banner

_cli's show_banner() calls _resolve_active_context_length() at every
startup. For non-OpenRouter providers (e.g. minimax-cn, kimi-coding,
custom endpoints) the resolver falls through to step 6 (OpenRouter
live /models fetch), which blocks ~2-3s per CLI launch and adds up
to 7+ minutes when openrouter.ai is unreachable through a proxy that
403s CONNECT (#46620).

Two complementary changes:

1. model_tools.py: read model.context_length from config.yaml and pass
   it as config_context_length to get_model_context_length. The
   step-0 config override short-circuits the entire resolution chain
   including the OpenRouter fetch. No network call is made when the
   user has set the value explicitly.

2. agent/model_metadata.py: replace flat timeout=10 with (5, 10)
   tuple at all five sites (fetch_model_metadata + four endpoint
   probes). urllib3 can otherwise block for 10s per retry stage
   through proxies that 403 CONNECT. The tuple bounds connect at 5s
   while still allowing slow reads.

Complements the in-flight PR #46685 (which adds HERMES_DISABLE_MODEL_METADATA
env var + same timeout tuple change for fetch_model_metadata). This PR
extends the timeout fix to the other four endpoint probes and adds the
config-override path that addresses the slow-but-reachable scenario
where env-var disable is too heavy-handed.

Refs #46620, PR #46685.

(cherry picked from commit e7faa34)
santhreal pushed a commit to santhreal/hermes-agent that referenced this pull request Jul 13, 2026
… on banner

_cli's show_banner() calls _resolve_active_context_length() at every
startup. For non-OpenRouter providers (e.g. minimax-cn, kimi-coding,
custom endpoints) the resolver falls through to step 6 (OpenRouter
live /models fetch), which blocks ~2-3s per CLI launch and adds up
to 7+ minutes when openrouter.ai is unreachable through a proxy that
403s CONNECT (NousResearch#46620).

Two complementary changes:

1. model_tools.py: read model.context_length from config.yaml and pass
   it as config_context_length to get_model_context_length. The
   step-0 config override short-circuits the entire resolution chain
   including the OpenRouter fetch. No network call is made when the
   user has set the value explicitly.

2. agent/model_metadata.py: replace flat timeout=10 with (5, 10)
   tuple at all five sites (fetch_model_metadata + four endpoint
   probes). urllib3 can otherwise block for 10s per retry stage
   through proxies that 403 CONNECT. The tuple bounds connect at 5s
   while still allowing slow reads.

Complements the in-flight PR NousResearch#46685 (which adds HERMES_DISABLE_MODEL_METADATA
env var + same timeout tuple change for fetch_model_metadata). This PR
extends the timeout fix to the other four endpoint probes and adds the
config-override path that addresses the slow-but-reachable scenario
where env-var disable is too heavy-handed.

Refs NousResearch#46620, PR NousResearch#46685.

(cherry picked from commit e7faa34)
justemu pushed a commit to justemu/hermes-agent that referenced this pull request Jul 18, 2026
… on banner

_cli's show_banner() calls _resolve_active_context_length() at every
startup. For non-OpenRouter providers (e.g. minimax-cn, kimi-coding,
custom endpoints) the resolver falls through to step 6 (OpenRouter
live /models fetch), which blocks ~2-3s per CLI launch and adds up
to 7+ minutes when openrouter.ai is unreachable through a proxy that
403s CONNECT (NousResearch#46620).

Two complementary changes:

1. model_tools.py: read model.context_length from config.yaml and pass
   it as config_context_length to get_model_context_length. The
   step-0 config override short-circuits the entire resolution chain
   including the OpenRouter fetch. No network call is made when the
   user has set the value explicitly.

2. agent/model_metadata.py: replace flat timeout=10 with (5, 10)
   tuple at all five sites (fetch_model_metadata + four endpoint
   probes). urllib3 can otherwise block for 10s per retry stage
   through proxies that 403 CONNECT. The tuple bounds connect at 5s
   while still allowing slow reads.

Complements the in-flight PR NousResearch#46685 (which adds HERMES_DISABLE_MODEL_METADATA
env var + same timeout tuple change for fetch_model_metadata). This PR
extends the timeout fix to the other four endpoint probes and adds the
config-override path that addresses the slow-but-reachable scenario
where env-var disable is too heavy-handed.

Refs NousResearch#46620, PR NousResearch#46685.

(cherry picked from commit e7faa34)
Gravezzz pushed a commit to Gravezzz/hermes-agent that referenced this pull request Jul 21, 2026
… on banner

_cli's show_banner() calls _resolve_active_context_length() at every
startup. For non-OpenRouter providers (e.g. minimax-cn, kimi-coding,
custom endpoints) the resolver falls through to step 6 (OpenRouter
live /models fetch), which blocks ~2-3s per CLI launch and adds up
to 7+ minutes when openrouter.ai is unreachable through a proxy that
403s CONNECT (NousResearch#46620).

Two complementary changes:

1. model_tools.py: read model.context_length from config.yaml and pass
   it as config_context_length to get_model_context_length. The
   step-0 config override short-circuits the entire resolution chain
   including the OpenRouter fetch. No network call is made when the
   user has set the value explicitly.

2. agent/model_metadata.py: replace flat timeout=10 with (5, 10)
   tuple at all five sites (fetch_model_metadata + four endpoint
   probes). urllib3 can otherwise block for 10s per retry stage
   through proxies that 403 CONNECT. The tuple bounds connect at 5s
   while still allowing slow reads.

Complements the in-flight PR NousResearch#46685 (which adds HERMES_DISABLE_MODEL_METADATA
env var + same timeout tuple change for fetch_model_metadata). This PR
extends the timeout fix to the other four endpoint probes and adds the
config-override path that addresses the slow-but-reachable scenario
where env-var disable is too heavy-handed.

Refs NousResearch#46620, PR NousResearch#46685.

(cherry picked from commit e7faa34)
leewenjie pushed a commit to leewenjie/hermes-agent that referenced this pull request Aug 7, 2026
… on banner

_cli's show_banner() calls _resolve_active_context_length() at every
startup. For non-OpenRouter providers (e.g. minimax-cn, kimi-coding,
custom endpoints) the resolver falls through to step 6 (OpenRouter
live /models fetch), which blocks ~2-3s per CLI launch and adds up
to 7+ minutes when openrouter.ai is unreachable through a proxy that
403s CONNECT (NousResearch#46620).

Two complementary changes:

1. model_tools.py: read model.context_length from config.yaml and pass
   it as config_context_length to get_model_context_length. The
   step-0 config override short-circuits the entire resolution chain
   including the OpenRouter fetch. No network call is made when the
   user has set the value explicitly.

2. agent/model_metadata.py: replace flat timeout=10 with (5, 10)
   tuple at all five sites (fetch_model_metadata + four endpoint
   probes). urllib3 can otherwise block for 10s per retry stage
   through proxies that 403 CONNECT. The tuple bounds connect at 5s
   while still allowing slow reads.

Complements the in-flight PR NousResearch#46685 (which adds HERMES_DISABLE_MODEL_METADATA
env var + same timeout tuple change for fetch_model_metadata). This PR
extends the timeout fix to the other four endpoint probes and adds the
config-override path that addresses the slow-but-reachable scenario
where env-var disable is too heavy-handed.

Refs NousResearch#46620, PR NousResearch#46685.

(cherry picked from commit e7faa34)
randlee pushed a commit to randlee/hermes-agent that referenced this pull request Aug 11, 2026
… on banner

_cli's show_banner() calls _resolve_active_context_length() at every
startup. For non-OpenRouter providers (e.g. minimax-cn, kimi-coding,
custom endpoints) the resolver falls through to step 6 (OpenRouter
live /models fetch), which blocks ~2-3s per CLI launch and adds up
to 7+ minutes when openrouter.ai is unreachable through a proxy that
403s CONNECT (NousResearch#46620).

Two complementary changes:

1. model_tools.py: read model.context_length from config.yaml and pass
   it as config_context_length to get_model_context_length. The
   step-0 config override short-circuits the entire resolution chain
   including the OpenRouter fetch. No network call is made when the
   user has set the value explicitly.

2. agent/model_metadata.py: replace flat timeout=10 with (5, 10)
   tuple at all five sites (fetch_model_metadata + four endpoint
   probes). urllib3 can otherwise block for 10s per retry stage
   through proxies that 403 CONNECT. The tuple bounds connect at 5s
   while still allowing slow reads.

Complements the in-flight PR NousResearch#46685 (which adds HERMES_DISABLE_MODEL_METADATA
env var + same timeout tuple change for fetch_model_metadata). This PR
extends the timeout fix to the other four endpoint probes and adds the
config-override path that addresses the slow-but-reachable scenario
where env-var disable is too heavy-handed.

Refs NousResearch#46620, PR NousResearch#46685.

(cherry picked from commit e7faa34)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint P1 High — major feature broken, no workaround provider/openrouter OpenRouter aggregator sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Gateway startup hangs when OpenRouter model-metadata fetch can't reach openrouter.ai (proxy 403 / no egress)

4 participants