Conversation
…ejection - Raise silent-rejection cap from 64 → 256 chars so Home Assistant Supervisor ingress prefixes (e.g. /api/hassio_ingress/<token>/dashboard, up to ~73+ chars) and other deep path-prefix gateways pass validation. - Add _warn_malformed_prefix() mirroring the existing dedup pattern in _warn_if_malformed_public_url() — a misconfigured proxy no longer silently discards the prefix and leaves the SPA loading a blank white page with zero logs. - Kept all other validation (path traversal, control chars, double slash) unchanged. Closes #59476
…l bindings _handle_message_with_agent()'s auto-skill block (Telegram DM Topics, Discord channel_skill_bindings) loads bound skills via _load_skill_payload() with a raw identifier, bypassing get_skill_commands()'s scan-time disabled filter. Result: a skill an operator disables for a platform (or globally, via skills.disabled) still gets its full content injected into every new session bound to that channel/topic. The stacked-skill (#58888) and bundle (#59156) invocation paths already re-check get_disabled_skill_names() for exactly this reason — the auto-skill block was the one path in gateway/run.py still missing it. Fix: check each resolved skill's name against get_disabled_skill_names(platform=...) before injecting it, skip and log disabled ones. Mirrors the existing stacked/bundle gates exactly (same helper, same platform scoping, same log style). No behavior change for any binding that references an enabled skill. - gateway/run.py: re-check get_disabled_skill_names() in the auto-skill loading loop, skipping disabled skills (+14 lines) - tests/gateway/test_auto_skill_platform_disabled.py: new regression test verifying the fix via source-code inspection (mirrors test_10710_auto_reset_evicts_cached_agent.py approach; verified: fails without the fix, passes with it)
alt-glitch
added
type/bug
Duplicate of #59478. Heads up: this PR's description (proxy-mode |
|
Closing: PR body describes proxy |
|
Stale/mismatched PR — proxy fix already on main; remainder duplicates #59478. |
2 participants
Summary
Fixes a bug in proxy mode where
_run_agent_via_proxy()returnedhistory_offset=len(history)(raw history length includingsession_metaentries) instead of the filteredagent_historylength. This caused transcript persistence to skip valid new messages when the gateway transcript containedsession_metaentries.Changes
gateway/run.pyagent_historyin proxy mode using the same filtering logic as_build_gateway_agent_history()(skipssession_meta,system, stripstimestamp/observedfrom tool messages)_run_agent_via_proxy()now uselen(agent_history)forhistory_offsetapi_messagessent to remote still contains compact user/assistant turns (unchanged behavior)tests/gateway/test_proxy_mode.pytest_history_offset_uses_filtered_length— verifieshistory_offset == 2when raw history has 1session_meta+ 2 conversation messagestest_history_offset_with_system_and_tool_messages— verifiessession_meta,system, and tool messages are all filtered correctly (raw 6 → filtered 4)Testing
_run_agentreturn at line 18516 which uses_effective_history_offsetbased onlen(agent_history))Root Cause
The proxy path was returning the raw
len(history)ashistory_offset, but the transcript persistence code (line 11665) slicesagent_messages[history_offset:]assuming the offset matches the filtered history the agent actually received. Whensession_metaentries exist in the transcript, the raw length is larger than the filtered length, causing valid new messages to be skipped during persistence.