Repository navigation
fix: an audio file's path takes the place of [voice] - #31
Merged
Merged
Conversation
Telegram, OneBot and Delta Chat write [voice] for a voice message, but the agent placed an audio file's path only at [audio] placeholders, so without transcription the path went after the text and [voice] stayed. A bare [voice] now takes it; [voice: ...] is a transcript and doesn't.
…aren't transcribed again Telegram wrote placeholders for a quoted photo, document, voice or audio message even when the reply carried no file for them (photos and documents never, voice and audio when their download failed), so the path of the reply's own file could land in the quote; with [voice] now taking audio paths, a quoted voice could too. Such quoted media is now only named. Transcription's annotation pattern no longer matches a transcript, so preparing a message again can't replace one.
mekjr1
force-pushed
the
fix/agent-path-tags-in-order
branch
from
October 7, 2026 19:29
507af44 to
f348a5f
Compare
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.
Telegram, OneBot and Delta Chat write
[voice]in the text for a voice message. The agent replaces placeholders with the stored files' paths by type (injectPathTags,pkg/agent/agent_media.go), and an audio file only took[audio]placeholders. So when the voice message wasn't transcribed (no transcription set up, or it failed), its path went after the text and[voice]stayed.A bare
[voice]now takes an audio file's path.[voice: what was said], which transcription writes, is not a placeholder; the transcribed file has also left the message's media by then.I also tried placing paths by order instead of by type, so that a
[file]whose bytes are an image would take that image. A survey of the channels ruled it out: Feishu, Weixin, Telegram (quotes), QQ (failed downloads), WeCom (mixed messages) and Delta Chat add refs without placeholders, or keep placeholders without refs, or write them out of order. With matching by order, or[file]taking any kind, those would put paths in the wrong place, so matching stays by type.Tests: two rows in
TestInjectPathTags_HandlesVariousChannelPlaceholders.[voice]fails without the fix; the transcript row fails if the pattern also matches[voice: …].