Skip to content

Conversation

@endolith
Copy link
Contributor

@endolith endolith commented Nov 18, 2025

Add missing display_markdown_message import in respond.py

and fix missing parentheses in conditionals

(and then some other changes, each of which should be pretty easy to approve)

Describe the changes you have made:

Reference any relevant issues (e.g. "Fixes #000"):

Pre-Submission Checklist (optional but appreciated):

  • I have included relevant documentation updates (stored in /docs)
  • I have read docs/CONTRIBUTING.md
  • I have read docs/ROADMAP.md

OS Tests (optional but appreciated):

  • Tested on Windows
  • Tested on MacOS
  • Tested on Linux

Add missing display_markdown_message import in respond.py
Added parentheses to fix two conditions that incorrectly triggered due
to operator precedence:
- API key handler triggered on any "api key" error, ignoring offline status
- Rate limit handler triggered on any "insufficient_quota" error, not
  just RateLimitError exceptions
Replace `type(e) == litellm.exceptions.RateLimitError` with
`isinstance(e, litellm.exceptions.RateLimitError)` for proper exception
type checking.

While technically different behavior (isinstance() supports
inheritance while type() == requires exact match), isinstance() is the
correct and more robust approach for exception handling. If litellm
introduces subclasses of RateLimitError in the future, isinstance() will
correctly catch them.
Replace `any([...])` with `any(...)` using a generator expression. This
improves performance by enabling short-circuiting - any() will stop
evaluating as soon as it finds a True value, rather than building the
entire list first. This is more memory efficient and potentially faster,
especially when the first item matches.
@endolith endolith force-pushed the display_markdown_message_is_not_defined branch from de544f8 to 38b04df Compare November 19, 2025 00:26
@endolith endolith changed the title Fix "display_markdown_message is not defined" Several small fixes to respond() Nov 19, 2025
The comment describes removing highlighting when code execution finishes.
The codebase consistently uses "highlight" terminology (highlight_active_line
setting, "highlight the active line" in docs). "unlightlight" is not used
elsewhere and appears to be a typo for "unhighlight".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant