Summary

LINE: file-type audio attachments not transcribed (0-byte download + missed audio detection)

Description

When a user sends an audio file via LINE's file upload feature (as opposed to the built-in hold-to-talk voice message), the file is not transcribed. Two issues occur:

1. 0-byte download: The downloaded file is empty (0 bytes), saved with a .bin extension
2. Audio detection miss: Even if the download succeeded, file-type messages are not routed through the audio transcription pipeline

Reproduction

1. Send a recorded audio file via LINE's file upload feature (not hold-to-talk)
2. Observe the attachment arrives as a 0-byte .bin file
3. No transcription is produced

Expected behavior

Audio files sent via LINE file upload should be downloaded successfully and transcribed using the configured tools.media.audio provider (e.g. Google Gemini), same as audio-type voice messages.

Root cause analysis

Traced through auth-profiles-B5ypC5S-.js:

Issue 1 — 0-byte download

downloadLineMedia() calls LINE's getMessageContent API. For file-type messages, this appears to return an empty response body, resulting in a 0-byte file. The audio-type messages work correctly with the same function.

Issue 2 — Audio detection miss

Even if the file downloads successfully, the pipeline doesn't recognize it as audio:

// extractMediaPlaceholder: file → "<media:document>" (not "<media:audio>")
case "file": return "<media:document>";

// resolveAttachmentKind: relies on contentType/extension detection
// If detectContentType can't identify the format → .bin extension → not recognized as audio

The resolveAttachmentKind() function checks contentType and file extension to determine if an attachment is audio. For file-type messages, if detectContentType() fails to identify the audio format from the buffer's magic bytes, the file gets a .bin extension and is never routed to the transcription pipeline.

Environment

• OpenClaw version: 2026.3.28
• Platform: ARM64 (iStoreOS / Linux 6.6.141)
• LINE channel: configured and working for audio-type voice messages
• Audio transcription: configured with google/gemini-3.1-flash-lite (works correctly for voice messages)

Suggested fix

1. Investigate why getMessageContent returns empty body for file-type messages (possibly need to use a different LINE API endpoint, or the file message's content provider differs)
2. For file-type messages, attempt audio detection using the original fileName and fileSize fields from the LINE FileMessage content, rather than relying solely on detectContentType magic bytes
3. Consider checking the LINE message's fileName extension (e.g. .m4a, .mp3, .wav) to determine if a file-type message should be treated as audio

Problem to solve

Users who send audio files via LINE's file upload feature (e.g. sharing a pre-recorded voice memo) cannot get their messages transcribed. The audio transcription pipeline only works for LINE's built-in hold-to-talk voice messages (audio type), but not for file type audio uploads. This is inconsistent — both are audio content that should be processed the same way. Currently the file arrives as a 0-byte .bin attachment with no transcription, making the message unreadable to the agent（e.g. openclaw）

Proposed solution

1. Fix the 0-byte download issue for file-type messages — investigate why LINE's getMessageContent API returns an empty body for file uploads, and use the correct API endpoint or content retrieval method if needed.

2. Detect audio within file-type messages by checking the LINE FileMessage.fileName extension (e.g. .m4a, .mp3, .wav, .ogg, .aac) — if the extension matches known audio formats, treat the attachment as audio and route it through the tools.media.audio transcription pipeline, same as audio-type voice messages.

3. Fallback: if detectContentType() magic-byte detection fails but the original fileName has an audio extension, use that extension for the saved file (instead of defaulting to .bin), so resolveAttachmentKind() can correctly identify it as audio.

Alternatives considered

No response

Impact

Affected: All LINE channel users who send audio via file upload instead of hold-to-talk voice message. Confirmed on OpenClaw 2026.3.28 (ARM64, iStoreOS).

Severity: Blocks workflow — the agent receives a 0-byte .bin file and cannot process the audio content at all. The user's message is effectively lost.

Frequency: Always reproducible — every file-type audio upload fails, not intermittent.

Consequence: Users must be aware of the distinction between LINE's voice message vs file upload, and remember to always use hold-to-talk. If they use file upload (a natural action for sharing pre-recorded audio), their message is silently ignored. This creates confusion and requires re-sending via the correct method, adding manual friction to everyday communication.

Evidence/examples

No response

Additional information

No response