fix: handle data URI audio refs in audio preprocessing and truncate warning log#8715
Open
Foolllll-J wants to merge 2 commits into
Open
fix: handle data URI audio refs in audio preprocessing and truncate warning log#8715Foolllll-J wants to merge 2 commits into
Foolllll-J wants to merge 2 commits into
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The
data:URI handling in_audio_ref_to_local_pathonly matchesaudio/\w+and will miss common MIME types likeaudio/x-wavoraudio/webm;codecs=opus; consider relaxing the regex and/or defaulting to a generic suffix when the subtype is not a simple word. - When decoding and writing the data-URI audio in
_audio_ref_to_local_path, it may be safer to wrap the base64 decode and file write in atry/exceptand fall back to the existing error-handling path so that malformed data URIs don't raise uncaught exceptions before_resolve_audio_part's try/except.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `data:` URI handling in `_audio_ref_to_local_path` only matches `audio/\w+` and will miss common MIME types like `audio/x-wav` or `audio/webm;codecs=opus`; consider relaxing the regex and/or defaulting to a generic suffix when the subtype is not a simple word.
- When decoding and writing the data-URI audio in `_audio_ref_to_local_path`, it may be safer to wrap the base64 decode and file write in a `try/except` and fall back to the existing error-handling path so that malformed data URIs don't raise uncaught exceptions before `_resolve_audio_part`'s try/except.
## Individual Comments
### Comment 1
<location path="astrbot/core/provider/sources/openai_source.py" line_range="360-369" />
<code_context>
async def _audio_ref_to_local_path(self, audio_ref: str) -> tuple[str, list[Path]]:
cleanup_paths: list[Path] = []
+ if audio_ref.startswith("data:"):
+ m = re.match(r"^data:audio/(\w+);base64,(.+)$", audio_ref)
+ if m:
+ suffix = f".{m.group(1)}"
+ audio_bytes = base64.b64decode(m.group(2))
+ temp_dir = Path(get_astrbot_temp_path())
+ temp_dir.mkdir(parents=True, exist_ok=True)
+ target_path = temp_dir / f"provider_audio_{uuid.uuid4().hex}{suffix}"
+ target_path.write_bytes(audio_bytes)
+ cleanup_paths.append(target_path)
+ return str(target_path), cleanup_paths
if audio_ref.startswith("http"):
suffix = Path(urlparse(audio_ref).path).suffix or ".wav"
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Consider guarding against very large data: URIs before base64 decoding
Decoding an unbounded `data:` URI directly into memory can be abused for DoS via excessive memory/CPU. Consider enforcing a maximum allowed payload size (e.g., check `len(m.group(2))` before `base64.b64decode` and reject oversized inputs) to make this path safer for untrusted input.
Suggested implementation:
```python
async def _audio_ref_to_local_path(self, audio_ref: str) -> tuple[str, list[Path]]:
cleanup_paths: list[Path] = []
if audio_ref.startswith("data:"):
m = re.match(r"^data:audio/(\w+);base64,(.+)$", audio_ref)
if m:
suffix = f".{m.group(1)}"
base64_payload = m.group(2)
# Guard against excessively large data: URIs before decoding
# The base64 length is ~4/3 of the decoded size; this keeps decoded audio under a safe cap.
max_base64_length = 8 * 1024 * 1024 # ~8MB base64, ~6MB decoded
if len(base64_payload) > max_base64_length:
truncated = audio_ref[:256] if len(audio_ref) > 256 else audio_ref
logger.warning(
"音频 data: URI 过大，已拒绝。长度: %d，最大允许: %d，前缀: %s",
len(base64_payload),
max_base64_length,
truncated,
)
raise ValueError("data: URI payload too large")
audio_bytes = base64.b64decode(base64_payload, validate=True)
temp_dir = Path(get_astrbot_temp_path())
temp_dir.mkdir(parents=True, exist_ok=True)
target_path = temp_dir / f"provider_audio_{uuid.uuid4().hex}{suffix}"
target_path.write_bytes(audio_bytes)
cleanup_paths.append(target_path)
return str(target_path), cleanup_paths
if audio_ref.startswith("http"):
```
1. Ensure that `logger` is available in this module (it appears to be used later in this function; if not already defined/imported, a module-level logger should be configured).
2. If you have a shared configuration or constants module for size limits, consider replacing the hard-coded `max_base64_length` with a named constant imported from there to keep limits consistent across the codebase.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+360
to
+369
| if audio_ref.startswith("data:"): | ||
| m = re.match(r"^data:audio/(\w+);base64,(.+)$", audio_ref) | ||
| if m: | ||
| suffix = f".{m.group(1)}" | ||
| audio_bytes = base64.b64decode(m.group(2)) | ||
| temp_dir = Path(get_astrbot_temp_path()) | ||
| temp_dir.mkdir(parents=True, exist_ok=True) | ||
| target_path = temp_dir / f"provider_audio_{uuid.uuid4().hex}{suffix}" | ||
| target_path.write_bytes(audio_bytes) | ||
| cleanup_paths.append(target_path) |
Contributor
There was a problem hiding this comment.
🚨 suggestion (security): Consider guarding against very large data: URIs before base64 decoding
Decoding an unbounded data: URI directly into memory can be abused for DoS via excessive memory/CPU. Consider enforcing a maximum allowed payload size (e.g., check len(m.group(2)) before base64.b64decode and reject oversized inputs) to make this path safer for untrusted input.
Suggested implementation:
async def _audio_ref_to_local_path(self, audio_ref: str) -> tuple[str, list[Path]]:
cleanup_paths: list[Path] = []
if audio_ref.startswith("data:"):
m = re.match(r"^data:audio/(\w+);base64,(.+)$", audio_ref)
if m:
suffix = f".{m.group(1)}"
base64_payload = m.group(2)
# Guard against excessively large data: URIs before decoding
# The base64 length is ~4/3 of the decoded size; this keeps decoded audio under a safe cap.
max_base64_length = 8 * 1024 * 1024 # ~8MB base64, ~6MB decoded
if len(base64_payload) > max_base64_length:
truncated = audio_ref[:256] if len(audio_ref) > 256 else audio_ref
logger.warning(
"音频 data: URI 过大，已拒绝。长度: %d，最大允许: %d，前缀: %s",
len(base64_payload),
max_base64_length,
truncated,
)
raise ValueError("data: URI payload too large")
audio_bytes = base64.b64decode(base64_payload, validate=True)
temp_dir = Path(get_astrbot_temp_path())
temp_dir.mkdir(parents=True, exist_ok=True)
target_path = temp_dir / f"provider_audio_{uuid.uuid4().hex}{suffix}"
target_path.write_bytes(audio_bytes)
cleanup_paths.append(target_path)
return str(target_path), cleanup_paths
if audio_ref.startswith("http"):- Ensure that
loggeris available in this module (it appears to be used later in this function; if not already defined/imported, a module-level logger should be configured). - If you have a shared configuration or constants module for size limits, consider replacing the hard-coded
max_base64_lengthwith a named constant imported from there to keep limits consistent across the codebase.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request adds support for processing base64-encoded data: URI audio references by decoding them and saving them to temporary files. It also truncates the logged audio reference in case of preprocessing failures to prevent bloated logs. The review feedback highlights a potential performance issue when running regex on large base64 payloads and suggests splitting the string first. Additionally, it requests adding unit tests to verify the new functionality.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
|
||
| async def _audio_ref_to_local_path(self, audio_ref: str) -> tuple[str, list[Path]]: | ||
| cleanup_paths: list[Path] = [] | ||
| if audio_ref.startswith("data:"): |
Contributor
There was a problem hiding this comment.
Please add corresponding unit tests to verify the handling of data: URI audio references, ensuring that decoding, temp file creation, and error handling work as expected.
References
- New functionality, such as handling attachments, should be accompanied by corresponding unit tests.
…nAI provider Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
dosubot
Bot
added
the
size:S
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
2 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.
Problem: When a user quotes (replies to) a voice message in group chat and @ the bot, the system includes the referenced audio in the LLM request.
_resolve_audio_partreceives adata:audio/wav;base64,...data URI for the audio, but_audio_ref_to_local_pathdoes not handle thedata:scheme — it only recognizeshttp://andfile://prefixes. It falls through toreturn audio_ref, cleanup_paths, and subsequentPath(data_uri).read_bytes()crashes because a data URI is not a valid file path. The error handler then logs the full base64 string (potentially megabytes) as a WARNING, flooding the log.Fix:
data:branch in_audio_ref_to_local_paththat decodes the base64 payload, writes it to a temp file, and returns the file path for normal processing.audio_refto 256 characters in the warning log to prevent log pollution.Modifications / 改动点
astrbot/core/provider/sources/openai_source.py:_audio_ref_to_local_path: addedif audio_ref.startswith("data:")branch — regex-matchdata:audio/\w+;base64,..., decode base64, write to temp file, return path_resolve_audio_part: truncatedaudio_refto 256 chars in thelogger.warningcallScreenshots or Test Results / 运行截图或测试结果
Before — full base64 dumped as WARNING (line truncated at 2000 chars, actual data is much longer):
After —
data:URI is correctly decoded, written to a temp WAV file, and passed to the LLM.Checklist / 检查清单
😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
/ 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。
👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
/ 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。
🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in
requirements.txtandpyproject.toml./ 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到
requirements.txt和pyproject.toml文件相应位置。😮 My changes do not introduce malicious code.
/ 我的更改没有引入恶意代码。
Summary by Sourcery
Handle data URI audio references during audio preprocessing and reduce verbosity of failure logs.
Bug Fixes:
Enhancements: