Conversation
|
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| description = "Agent Framework plugin for Blaze AI services (STT, TTS, LLM)." | ||
| readme = "README.md" | ||
| license = "Apache-2.0" | ||
| requires-python = ">=3.10.0" |
There was a problem hiding this comment.
🔴 Plugin package drops required Python 3.9 compatibility
The new Blaze plugin package declares requires-python = ">=3.10.0", which violates the repository’s mandatory rule that code must maintain Python 3.9+ compatibility (AGENTS.md). This makes the plugin uninstallable on supported 3.9 environments and is a direct policy violation that must be fixed before merge (livekit-plugins/livekit-plugins-blaze/pyproject.toml:11).
| requires-python = ">=3.10.0" | |
| requires-python = ">=3.9.0" |
Was this helpful? React with 👍 or 👎 to provide feedback.
| # Build URL with query parameters using httpx for proper encoding | ||
| query_params: Dict[str, str] = { | ||
| "is_voice_call": "true", | ||
| "use_tool_based": "true", |
There was a problem hiding this comment.
🟡 enable_tools option is never applied to LLM request parameters
LLM.__init__ and update_options store _enable_tools, but _run always sends "use_tool_based": "true" unconditionally. As a result, callers cannot actually disable tool mode, even when enable_tools=False, so runtime behavior contradicts the public API and option contract (livekit-plugins/livekit-plugins-blaze/livekit/plugins/blaze/llm.py:73, livekit-plugins/livekit-plugins-blaze/livekit/plugins/blaze/llm.py:123-143).
| "use_tool_based": "true", | |
| "use_tool_based": "true" if self._llm._enable_tools else "false", |
Was this helpful? React with 👍 or 👎 to provide feedback.
| self._language = language | ||
| self._auth_token = auth_token or self._config.auth_token | ||
| self._sample_rate = sample_rate | ||
| self._timeout = timeout or self._config.stt_timeout |
There was a problem hiding this comment.
🟡 Explicit STT timeout override is ignored for falsy values
The STT constructor documents explicit-args-over-config precedence, but uses self._timeout = timeout or self._config.stt_timeout. This treats 0/0.0 as unset and silently replaces the caller’s explicit timeout with config/default, violating the stated precedence and making timeout behavior incorrect for valid falsy inputs.
| self._timeout = timeout or self._config.stt_timeout | |
| self._timeout = timeout if timeout is not None else self._config.stt_timeout |
Was this helpful? React with 👍 or 👎 to provide feedback.
| self._agentic_search = agentic_search | ||
| self._enable_tools = enable_tools | ||
| self._demographics = demographics | ||
| self._timeout = timeout or self._config.llm_timeout |
There was a problem hiding this comment.
🟡 Explicit LLM/TTS timeout overrides are ignored for falsy values
Both LLM and TTS constructors use timeout or config_timeout, so explicitly provided 0/0.0 values are discarded and replaced by config defaults. This makes runtime timeout configuration inconsistent with constructor inputs and can break callers relying on exact timeout control.
Prompt for agents
Update timeout assignment logic to preserve explicit falsy values in both constructors: livekit-plugins/livekit-plugins-blaze/livekit/plugins/blaze/llm.py line 91 in LLM.__init__, and livekit-plugins/livekit-plugins-blaze/livekit/plugins/blaze/tts.py line 96 in TTS.__init__. Replace `timeout or ...` with a None-check form (`timeout if timeout is not None else ...`) so explicit values like 0.0 are honored.
Was this helpful? React with 👍 or 👎 to provide feedback.
3 participants
No description provided.