fix(plugins/memory/honcho): default Honcho SDK HTTP timeout to 30s#13623
Closed
twozle wants to merge 1 commit into
Closed
fix(plugins/memory/honcho): default Honcho SDK HTTP timeout to 30s#13623twozle wants to merge 1 commit into
twozle wants to merge 1 commit into
Conversation
When no explicit timeout is configured (HonchoClientConfig.timeout, honcho.timeout / requestTimeout, or HONCHO_TIMEOUT), get_honcho_client previously constructed the SDK with no timeout kwarg, letting the underlying httpx client hang indefinitely if the Honcho backend became unreachable mid-request. This is a silent-failure hazard on the post-response path of run_conversation: the memory_manager.sync_all() / queue_prefetch_all() calls fire after the agent has already generated its final reply, so a stalled Honcho request blocks run_conversation from returning. The gateway never logs "response ready" and never delivers the response to the platform (Telegram, etc.), even though the text is already saved to the session file. Repro: unplug the network or block app.honcho.dev mid-turn after the model has produced its final message. Without this change, _run_agent never returns. With it, the call aborts after 30s, run_conversation returns, and the gateway delivers the response (Honcho sync failure is logged and swallowed as before). The default applies only when nothing is configured, so any deployment that has explicitly set timeout / HONCHO_TIMEOUT / honcho.timeout / honcho.requestTimeout keeps its existing value. Self-hosted deployments that genuinely need a longer ceiling can still override via any of those knobs.
Collaborator
This was referenced Apr 24, 2026
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
get_honcho_client()currently passes notimeoutkwarg to the Honcho SDK when nothing is explicitly configured (neitherHonchoClientConfig.timeout,honcho.timeout/requestTimeoutin the Hermes config, norHONCHO_TIMEOUT). The underlying httpx client then has no cap, so a stalled request can hang indefinitely.This is a silent-failure hazard on the post-response path of
run_conversation—memory_manager.sync_all()/queue_prefetch_all()fire after the agent has already generated its final reply, so a stuck Honcho call blocksrun_conversationfrom returning. The gateway never logsresponse readyand never delivers the reply to Telegram / WhatsApp / etc., even though the text is already saved to the session file.This PR adds a module-level
_DEFAULT_HTTP_TIMEOUT = 30.0and applies it inget_honcho_client()only after all configured sources have been checked, so existing deployments that have tuned the value (including self-hosted instances that need longer) keep their current behavior. Unconfigured installs get a sensible ceiling instead of silent indefinite hangs.Repro
Observed on v0.9.0 with the honcho plugin active and a Telegram session.
sync_allis running._run_agentnever returns, noresponse readyis logged, the Telegram reply is lost despite being present in the session file. The gateway process stays alive (Telegram long-poll is unaffected) but cannot complete the turn or respond to further messages in that chat until restarted. CLOSE-WAIT sockets to Honcho accumulate.run_conversationreturns,sync_turn failed: …is logged as before, and the gateway delivers the already-generated reply.Test plan
pytest tests/honcho_plugin/ tests/test_honcho_client_config.py— 160 passed locally (Python 3.12, honcho-ai installed)TestGetHonchoClient::test_defaults_to_30s_when_no_timeout_configuredasserts the default is passed when neitherHonchoClientConfig.timeoutnor a Hermes config override is settest_passes_timeout_from_config,test_hermes_config_timeout_override_used_when_config_timeout_missing,test_hermes_request_timeout_alias_usedstill pass unchanged — an explicit value continues to win over the defaultPlatforms tested
Linux only. The change is pure Python dict kwarg construction, no platform-sensitive code paths, so Windows / macOS behavior should be identical.