Skip to content

fix(qqbot): stop routing file uploads through STT pipeline - #35705

Closed
Zioywishing wants to merge 5 commits into
NousResearch:mainfrom
Zioywishing:fix-qq-voice-file-detection
Closed

fix(qqbot): stop routing file uploads through STT pipeline#35705
Zioywishing wants to merge 5 commits into
NousResearch:mainfrom
Zioywishing:fix-qq-voice-file-detection

Conversation

@Zioywishing

@Zioywishing Zioywishing commented May 31, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

Fixes #35704

Add a guard clause in _is_voice_content_type() to prevent audio file uploads from being misrouted through the STT pipeline.

Problem

When a user sends an audio file (.wav, .mp3, .ogg, etc.) via QQ's file transfer feature, the content_type is "file" — but the extension-based heuristic in _is_voice_content_type() still matches, causing the file to be consumed by the STT pipeline instead of being saved as a regular attachment.

Fix

  • Added an early return if ct == "file": return False before the extension check
  • This ensures file uploads (content_type="file") are never matched by the extension heuristic, even if the filename has an audio extension
  • Voice messages (content_type="voice") and raw audio types (audio/*) continue to work as before

Before/After

Before: File audio-30251.instrumental..wav with content_type="file" → matched by .wav extension → routed to STT → [Voice] [语音识别失败] → file lost

After: File audio-30251.instrumental..wav with content_type="file" → early return False → saved as regular file attachment ✓

Testing

Verified with actual QQ Bot message logs:

  • Voice message: content_type=voice, filename=xxx.amr → still correctly routed to STT ✓
  • File upload: content_type=file, filename=audio-30251.instrumental..wav → now saved as file ✓

@Zioywishing
fix(qqbot): stop routing file uploads through STT pipeline
640e057 
The _is_voice_content_type() heuristic matched audio file extensions
(.wav, .mp3, .ogg, etc.) even when the QQ Bot API explicitly reported
content_type='file'.  This caused files sent via QQ's file-transfer
feature to be routed through the speech-to-text pipeline instead of
being saved as regular attachments.

The QQ Bot API already distinguishes voice messages (content_type=
'voice') from file uploads (content_type='file'), so filename-based
extension sniffing is unnecessary and harmful.

Removed the _VOICE_EXTENSIONS fallback; now only content_type is
checked.

Closes #XXXX
@Zioywishing
test(qqbot): update voice detection tests for content_type-only logic
86e39bc 
Update TestIsVoiceContentType to match the new behavior:
- Empty content_type with audio extensions → False (no sniffing)
- File upload with audio extension → False
- Added test_file_upload_with_audio_extension for the reported bug case
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists platform/qqbot QQ Bot adapter comp/gateway Gateway runner, session dispatch, delivery tool/tts Text-to-speech and transcription labels May 31, 2026
@Zioywishing
fix(qqbot): keep extension fallback for voice detection, skip only fo…
e3f6dd4 
…r explicit file uploads

Refined the fix: instead of removing extension-based fallback entirely,
only skip it when content_type is explicitly 'file' (or image/video).
Empty or unknown content_types still fall back to extension matching
as a defensive measure.

- content_type='voice' or 'audio/*' → True (API signal)
- content_type='file' → False (file transfer, never voice)
- content_type='' → extension fallback (defensive)
- content_type=unknown → extension fallback (defensive)

Added _looks_like_voice() module-level helper and comprehensive tests.
@Zioywishing
fix(qqbot): skip voice detection for file uploads (content_type='file')
27fb0fe 
Minimal fix: add 'if ct == "file": return False' before extension
matching. The original fallback logic is preserved for empty/unknown
content_types. Only the bug case (file uploads with audio extensions)
is fixed.

Removed the over-engineered _looks_like_voice helper.
@Zioywishing
docs(qqbot): clarify comment on file upload guard
2f3d334
tonydwb
tonydwb approved these changes May 31, 2026
View reviewed changes

@tonydwb tonydwb left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review Summary

Verdict: Approved

Overview

Clean fix for QQ Bot audio file uploads being incorrectly routed through the STT pipeline. The _is_voice_content_type() function's extension-based heuristic matched .wav/.mp3/etc. file uploads (content_type="file") as voice, causing file loss after failed STT.

Looks Good

  • Correct logic: content_type="file" explicitly returns False, overriding extension fallback
  • Minimal change: Only the _VOICE_EXTENSIONS tuple and early-return guard changed
  • Comprehensive tests: Tests for content_type="file" with various audio extensions all return False
  • No regression: Voice messages with content_type="voice" or audio/* still work
  • Low blast radius: Single helper function, narrow scope
  • Real-world verified: Confirmed against actual QQ Bot message logs

Reviewed by Hermes Agent

@teknium1

teknium1 commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Thanks for the focused QQBot fix. The premise is confirmed on current main: gateway/platforms/qqbot/adapter.py:1812-1826 applies the audio-extension fallback even after receiving content_type="file"; the caller at gateway/platforms/qqbot/adapter.py:1700-1725 then routes that result into STT. Returning False for explicit QQ file uploads lets the existing normal-file branch at gateway/platforms/qqbot/adapter.py:1741-1750 cache and expose the attachment instead. The added predicate coverage covers the reported audio-file cases while preserving the existing empty-content-type fallback.

Automated hermes-sweeper review.

@teknium1 teknium1 added sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 13, 2026
@GottZ GottZ mentioned this pull request Jul 28, 2026
Closed
@teknium1 teknium1 mentioned this pull request Jul 28, 2026
Merged
@teknium1

teknium1 commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Merged into main via consolidated salvage PR #73515 (merge c911a5f10f). Your QQ fix keeping explicit file uploads out of the STT pipeline was cherry-picked with your authorship (full 5-commit sequence).

Your contribution is credited to you in git history. Thank you! Closing this PR as merged-via-salvage.

@teknium1 teknium1 closed this Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@tonydwb tonydwb tonydwb approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

comp/gateway Gateway runner, session dispatch, delivery P2 Medium — degraded but workaround exists platform/qqbot QQ Bot adapter sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages tool/tts Text-to-speech and transcription type/bug Something isn't working

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

QQ Bot: Audio files sent via file transfer are incorrectly routed to STT pipeline

4 participants

@Zioywishing @teknium1 @tonydwb @alt-glitch