fix(assistant): handle gif URLs breaking vision responses - #279
Merged
Conversation
A gif URL in a message was matched by the image URL regex and sent to the vision API, which returned a 400 "Error while downloading ...gif" (the API cannot process animated gifs), failing the entire response. - Exclude gif from the image URL regex to match the attachment handler, which already skipped gif. - Strip images and retry on "Error while downloading" in the BadRequestError handler so any unfetchable image URL degrades gracefully. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011vjHtN5hcQi9hGonuDbMEG
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a failure mode in the assistant chat flow where GIF URLs (and other unfetchable image URLs) could break the entire response by being forwarded to the vision API and triggering a 400 error.
Changes:
- Excludes
giffrom the inline image URL regex so GIF links are not sent to the vision API. - Extends
BadRequestErrorhandling to purge images and retry when the API returns “Error while downloading”. - Adds a
v8.18.3changelog entry documenting the fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| assistant/common/chat.py | Stops treating GIF URLs as vision images and retries gracefully on image-download 400s by stripping images. |
| assistant/CHANGELOG.md | Documents the bugfix and bumps changelog to v8.18.3. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
1059
to
+1063
| except openai.BadRequestError as e: | ||
| if "Invalid image" in str(e): | ||
| err_text = str(e) | ||
| # Some image URLs (e.g. gifs, or links the API can't fetch) cause a 400. Rather than | ||
| # failing the whole response, strip images from the payload and retry without them. | ||
| if "Invalid image" in err_text or "Error while downloading" in err_text: |
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
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.
Problem
When a message contained a GIF URL (e.g.
Mirosbird.gif), the bot failed the entire response with:Root cause
The image URL regex in
assistant/common/chat.pyincludedgif, so gif URLs were forwarded to the vision API. OpenAI's vision can't process (animated) gifs and returns a 400Error while downloading. The attachment handler right below it already excluded gif (img_ext = ["png", "jpg", "jpeg", "webp"]), so the two paths were inconsistent.Additionally, the
BadRequestErrorhandler only retried-without-images on"Invalid image", not"Error while downloading", so this error fell through and broke the whole reply.Fix
giffrom the image URL regex so gif URLs are no longer sent to the vision API, matching the attachment handler.BadRequestErrorhandler now also strips images and retries on"Error while downloading", so any unfetchable image URL degrades gracefully (text answer still returned) instead of failing the entire response.purge_images()already removes URL-sourced images, so the retry path works correctly.Bumped changelog to
v8.18.3.Generated by Claude Code