Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Audio/image/video transcription failures are silently swallowed unless debug logging is enabled [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60421•Fetched 2026-04-08 02:51:29
View on GitHub
Comments
1
Participants
1
Timeline
7
Reactions
0
Author
KurtVogelKurtVogel
Participants
KurtVogelKurtVogel
Timeline (top)
cross-referenced ×5commented ×1referenced ×1

All three catch boundaries in the media understanding pipeline log at verbose/debug level only. When an audio transcription fails (timeout, 5xx, empty response from Groq/OpenAI/Deepgram), the error is completely invisible at the default info log level.

Error Message

All three catch boundaries in the media understanding pipeline log at verbose/debug level only. When an audio transcription fails (timeout, 5xx, empty response from Groq/OpenAI/Deepgram), the error is completely invisible at the default info log level.

Error Suppression Chain

Log media understanding errors at warn level (not debug/verbose). These are external API failures that directly impact user experience and should always be visible in logs.

Root Cause

All three catch boundaries in the media understanding pipeline log at verbose/debug level only. When an audio transcription fails (timeout, 5xx, empty response from Groq/OpenAI/Deepgram), the error is completely invisible at the default info log level.

Fix Action

Fixed

PR fix notes

PR #60438: fix: log media understanding errors at warn level instead of verbose

Description (problem / solution / changelog)

Summary

Makes transcription failures visible at default log level by logging at warn level instead of verbose-only. This addresses issue #60421 where audio/image/video transcription failures are silently swallowed unless debug logging is enabled.

Changes

  • src/media-understanding/concurrency.ts: log MediaUnderstandingTaskError at warn level
  • src/media-understanding/runner.ts: log skip and failure errors at warn level

Good day!

Thank you for maintaining such an excellent project. I've noticed issue #60421 where transcription failures are logged only at verbose level, making them invisible at default log level. This PR upgrades those logs to warn level so users can see when transcription fails without enabling debug logging.

Looking at the code, I found two locations where errors are logged at verbose level:

  1. src/media-understanding/concurrency.ts - in the onTaskError callback
  2. src/media-understanding/runner.ts - in the catch blocks for skip and failure

The fix uses getLogger().warn() to log at warn level, with a console.error fallback if the logger fails. This ensures users can always see transcription failures in their logs.

If there's a better approach or if I've missed something, please let me know and I'll update the PR.

Warmly,

RoomWithOutRoof

Changed files

  • README.md (modified, +2/-2)
  • docs/channels/signal.md (modified, +39/-0)
  • docs/channels/telegram.md (modified, +4/-0)
  • docs/platforms/mac/signing.md (modified, +1/-1)
  • docs/platforms/windows.md (modified, +1/-1)
  • docs/plugins/community.md (modified, +75/-0)
  • docs/zh-CN/tools/diffs.md (added, +358/-0)
  • extensions/mattermost/src/mattermost/monitor.ts (modified, +1/-0)
  • pnpm-workspace.yaml (modified, +1/-0)
  • scripts/clawlog.sh (modified, +4/-4)
  • src/agents/pi-embedded-runner/google.ts (modified, +10/-2)
  • src/agents/system-prompt.ts (modified, +8/-2)
  • src/auto-reply/reply/mentions.ts (modified, +2/-2)
  • src/auto-reply/reply/reply-inline.ts (modified, +3/-3)
  • src/auto-reply/tokens.ts (modified, +4/-3)
  • src/cron/run-log.ts (modified, +1/-1)
  • src/discord/audit.ts (modified, +5/-0)
  • src/gateway/server-cron.ts (modified, +7/-6)
  • src/logging/subsystem.ts (modified, +10/-1)
  • src/media-understanding/concurrency.ts (modified, +8/-3)
  • src/media-understanding/runner.ts (modified, +12/-5)
  • src/telegram/bot-message-dispatch.ts (modified, +24/-0)
  • ui/src/ui/controllers/chat.ts (modified, +15/-0)
RAW_BUFFERClick to expand / collapse

Description

All three catch boundaries in the media understanding pipeline log at verbose/debug level only. When an audio transcription fails (timeout, 5xx, empty response from Groq/OpenAI/Deepgram), the error is completely invisible at the default info log level.

Error Suppression Chain

  1. runAttachmentEntries (runner) — catches errors, logs at verbose only
  2. runWithConcurrency onTaskError (apply) — logs at verbose only
  3. runTasksWithConcurrency — catches and continues by default

Result: user's voice message appears as <media:audio> with zero indication of why transcription failed. No log output at default level.

Impact

  • Voice messages intermittently fail to transcribe with no diagnostic output
  • Users must proactively enable debug logging to catch failures
  • Makes debugging transcription flakiness nearly impossible

Suggested Fix

Log media understanding errors at warn level (not debug/verbose). These are external API failures that directly impact user experience and should always be visible in logs.

Environment

  • OpenClaw 2026.4.2
  • Provider: Groq (whisper-large-v3-turbo)
  • Channel: Telegram DM

extent analysis

TL;DR

Log media understanding errors at the warn level instead of verbose to ensure visibility of transcription failures at the default log level.

Guidance

  • Identify the locations where errors are currently being logged at the verbose level, specifically in runAttachmentEntries and runWithConcurrency.
  • Update the log level for these errors to warn to make them visible at the default log level.
  • Verify that transcription failures are now logged at the warn level by checking the logs after a failed transcription attempt.
  • Consider reviewing other parts of the code to ensure that similar error handling mechanisms are not suppressing important error messages.

Example

# Before
logger.verbose("Error transcribing audio: %s", error)

# After
logger.warn("Error transcribing audio: %s", error)

Notes

This fix assumes that the logging framework being used supports a warn level and that it is configured to be visible at the default log level. Additionally, this fix may increase the noise in the logs if there are many transcription failures, so it may be worth considering additional logging configuration or error handling mechanisms.

Recommendation

Apply the suggested fix to log media understanding errors at the warn level, as this will provide better visibility into transcription failures and improve the ability to debug issues.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#conversation history#tool integration#LLM response#prompt template

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING