Every LibreNMS request sets the shared HTTP context timeout to 2_147_483_647 milliseconds (src/librenms-client.ts:94-102), which is about 24.8 days. There is no timeout setting in the client configuration or documented environment variables.
When the LibreNMS address accepts a connection but stops responding, or a firewall silently drops packets, an operator command or MCP tool call remains pending for days instead of returning an actionable unreachable error. The retry policy cannot help while the first attempt is still waiting, and automation waiting on the stdio response can remain blocked indefinitely.
Suggested direction: use a bounded default request timeout, expose a validated configuration override for legitimately slow installations, and add a test with a fetch promise that never settles to verify the client returns a timeout error within the configured interval.
Every LibreNMS request sets the shared HTTP context timeout to
2_147_483_647milliseconds (src/librenms-client.ts:94-102), which is about 24.8 days. There is no timeout setting in the client configuration or documented environment variables.When the LibreNMS address accepts a connection but stops responding, or a firewall silently drops packets, an operator command or MCP tool call remains pending for days instead of returning an actionable unreachable error. The retry policy cannot help while the first attempt is still waiting, and automation waiting on the stdio response can remain blocked indefinitely.
Suggested direction: use a bounded default request timeout, expose a validated configuration override for legitimately slow installations, and add a test with a fetch promise that never settles to verify the client returns a timeout error within the configured interval.