feat(dingtalk): support incoming audio messages via SDK extensions - #24861
Closed
zh-xl-kang wants to merge 1 commit into
Closed
feat(dingtalk): support incoming audio messages via SDK extensions#24861zh-xl-kang wants to merge 1 commit into
zh-xl-kang wants to merge 1 commit into
Conversation
alt-glitch
added
type/feature
zh-xl-kang
force-pushed
the
feat/dingtalk-audio-support
branch
2 times, most recently
from
May 13, 2026 07:15
5fed206 to
e3bdcc1
Compare
DingTalk's official API sends voice messages as msgtype=audio with a recognition field containing server-side ASR text. However, the dingtalk-stream SDK (v0.24.3) only parses text/picture/richText msgtypes into typed attributes; audio/video/file content lands in message.extensions as a raw dict. Changes: - _extract_text: read recognition from extensions['content'] for audio messages, falling back to a placeholder when ASR is unavailable - _extract_media: set MessageType.AUDIO without adding raw downloadCode to media_urls (the STT pipeline expects local file paths, not DingTalk download codes) Verified against dingtalk-stream SDK v0.24.3 with real single-chat (单聊) bot traffic.
zh-xl-kang
force-pushed
the
feat/dingtalk-audio-support
branch
from
May 13, 2026 07:21
e3bdcc1 to
cd5ca4a
Compare
Author
|
Gentle bump on this one — it's a clean +31/-0 addition to handle DingTalk voice messages (msgtype: audio) which the current stream SDK drops silently. The ASR recognition text gets extracted with two fallback paths. Tested against real DingTalk bot traffic. Would appreciate a review, thanks! |
Author
|
Closing in favor of #49546 — same feature (DingTalk audio ASR extraction) with a cleaner fix that handles both SDK recognition paths and the edge case where |
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.
Summary
DingTalk official API sends voice messages via Stream Mode as
msgtype: audiowith arecognitionfield containing server-side ASR text. Thedingtalk-streamSDK only parsestext/picture/richTextinto typed attributes; audio content lands inmessage.extensionsas raw dict.This PR adds handling for
msgtype: audioin the DingTalk adapter.Changes
_extract_text: readrecognitionfromextensions['content']for audio messages, with two fallback paths and a placeholder when ASR unavailable_extract_media: setMessageType.AUDIOwithout adding rawdownloadCodetomedia_urls(STT pipeline expects local paths)_IncomingHandler: INFO log for raw msgtype of every Stream callbackTesting
Verified with real DingTalk single-chat bot traffic against dingtalk-stream SDK v0.24.3. Voice messages with recognition are correctly extracted as text; messages without use a placeholder to avoid silent drops.