Enhance Reply chain handling for Record components

[tjc6666666666666]

Added processing for Record components within Reply chains, including WAV conversion and STT functionality.

Modifications / 改动点

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

---

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.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Handle audio Record components embedded in Reply chains during preprocessing for both WAV conversion and speech-to-text, while improving robustness of existing STT processing.

New Features:

• Enable WAV conversion for Record components contained within Reply message chains.
• Apply speech-to-text processing to Record components inside Reply chains so quoted voice messages are transcribed.

Enhancements:

• Refine existing Record STT handling with early filtering and improved error handling and logging for missing or invalid audio files.

[gemini-code-assist]

Code Review

This pull request adds support for processing and performing speech-to-text (STT) on Record components nested within Reply chains, including wav conversion and error handling. The review feedback suggests refactoring the highly duplicated STT logic for direct and nested Record components into a shared helper function to improve code maintainability and readability.

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.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The new logic for handling Record components in reply chains (both WAV conversion and STT) largely duplicates the existing top-level Record handling; consider extracting common helper functions to reduce repetition and keep behavior consistent.
• You now call event.get_messages() multiple times in the same process method and then iterate nested reply chains; if get_messages() has any cost or side effects, it may be cleaner to fetch once and reuse the list while traversing both top-level and reply components.
• Error logging and retry behavior for STT differs between top-level and reply-chain records (e.g., FileNotFoundError logging content, message texts, and retry handling); aligning these paths would make failures easier to debug and the behavior more predictable.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new logic for handling `Record` components in reply chains (both WAV conversion and STT) largely duplicates the existing top-level `Record` handling; consider extracting common helper functions to reduce repetition and keep behavior consistent.
- You now call `event.get_messages()` multiple times in the same `process` method and then iterate nested reply chains; if `get_messages()` has any cost or side effects, it may be cleaner to fetch once and reuse the list while traversing both top-level and reply components.
- Error logging and retry behavior for STT differs between top-level and reply-chain records (e.g., `FileNotFoundError` logging content, message texts, and retry handling); aligning these paths would make failures easier to debug and the behavior more predictable.

## Individual Comments

### Comment 1
<location path="astrbot/core/pipeline/preprocess_stage/stage.py" line_range="136-138" />
<code_context>
+                        logger.warning(f"重试中: {i + 1}/{retry}")
+                        await asyncio.sleep(0.5)
+                        continue
+                    except BaseException as e:
+                        logger.error(traceback.format_exc())
+                        logger.error(f"语音转文本失败: {e}")
+                        break
+
</code_context>
<issue_to_address>
**issue (bug_risk):** Catching `BaseException` is overly broad and may mask cancellation or system-level errors; prefer catching `Exception`.

This also catches `asyncio.CancelledError`, `KeyboardInterrupt`, and other system-level exceptions, which can prevent proper cancellation and shutdown. Here it should be narrowed to `except Exception as e:` while keeping the current logging and `break`. If you truly need to handle non-`Exception` errors, list those specific types instead of using `BaseException`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Catching BaseException is overly broad and may mask cancellation or system-level errors; prefer catching Exception.

This also catches asyncio.CancelledError, KeyboardInterrupt, and other system-level exceptions, which can prevent proper cancellation and shutdown. Here it should be narrowed to except Exception as e: while keeping the current logging and break. If you truly need to handle non-Exception errors, list those specific types instead of using BaseException.