fix: detect actual audio format for TTS Content-Type instead of assuming mpeg - #39652
Open
SpiliosDimakopoulos wants to merge 11 commits into
Open
fix: detect actual audio format for TTS Content-Type instead of assuming mpeg#39652SpiliosDimakopoulos wants to merge 11 commits into
SpiliosDimakopoulos wants to merge 11 commits into
Conversation
…ΘΜΟ>) 'Runing docker container' -> 'Running docker container'.
…ΘΜΟΣ>) ar-SA: unescape the quick-start-guide link and point it at the real heading slug (#البداية-السريعة). hi-IN: point the community link at the real bilingual heading slug (#समुदाय-और-संपर्क-community--contact). Verified both slugs with github-slugger.
validate_credentials() -> _get_request() called httpx.get() with no explicit timeout, unlike the Jina/Firecrawl/Nacos/Marketplace auth providers which were recently hardened with bounded httpx.Timeout values. A slow or hanging WaterCrawl endpoint could block the worker indefinitely during credential validation. Updated the existing unit test to assert the new timeout kwarg.
CursorResult.rowcount is sourced directly from the underlying DBAPI driver's cursor.rowcount. PEP 249 recommends -1 for 'unknown', but not all drivers follow that convention -- some return None. messages_deleted was added unguarded into stats['total_deleted'] (an int), which raises TypeError if rowcount comes back None. Same class of issue already fixed for the workflow bulk-delete methods in langgenius#38054; applying the same 'or 0' guard here. fixes #<ISSUE_NUMBER>
…ing mpeg invoke_tts() returns Iterable[bytes] with no format metadata, but AudioService.transcript_tts always hardcoded content_type=audio/mpeg on the streamed response. If a provider streams a different container (WAV/OGG/FLAC), the browser gets a mismatched Content-Type. Added a best-effort sniff of the first response chunk's magic bytes (RIFF/WAVE, OggS, fLaC, ID3/MP3 frame sync), falling back to the previous audio/mpeg default when unrecognized -- purely additive, no change for streams already labeled correctly. fixes #<ISSUE_NUMBER>
SpiliosDimakopoulos
requested review from
QuantumGhost,
crazywoola and
laipz8200
as code owners
July 27, 2026 11:13
dosubot
Bot
added
the
size:M
Contributor
Pyrefly Type Coverage
|
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
1 participant
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.
invoke_tts() returns Iterable[bytes] with no format metadata, but AudioService.transcript_tts always hardcoded content_type="audio/mpeg" on the streamed response, in both places it returns a Generator. If a model/plugin provider streams a different container (WAV, OGG, FLAC), the browser receives a Content-Type that doesn't match the actual bytes, which can break playback.
Added a best-effort sniff of the first response chunk's magic bytes (RIFF/WAVE, OggS, fLaC, ID3 tag or raw MP3 frame sync) to set the correct Content-Type, falling back to the previous audio/mpeg default when the format isn't recognized. This is purely additive — streams that were already being labeled correctly see no behavior change.
Note: I wasn't able to confirm from this repo alone whether a currently-shipped provider plugin returns non-MP3 audio in practice (provider implementations live in the separate plugin repos) — happy to narrow scope if a maintainer says this isn't currently reachable.