solution channel medium macos feishu

Feishu/Lark: iOS photo-library videos fail with 502 when OpenClaw downloads them as file type

Fix Feishu/Lark cases where an iOS photo-library video arrives as `file`, OpenClaw downloads it with `type=file`, and longer clips fail with 502. Use a safer send path now or add a bounded `type=media` fallback.

By CoClaw Team • March 18, 2026

Symptoms

You are probably in this exact failure pattern if all of the following are true:

the upload came from the iOS photo library, not from Feishu’s direct in-app video recording flow,
Feishu/Lark reports the message as file instead of video,
OpenClaw tries to download the attachment with ?type=file, and
the gateway logs show a 502 like:

feishu: failed to download media media: AxiosError: Request failed with status code 502
responseUrl: https://open.larksuite.com/open-apis/im/v1/messages/.../resources/...?...type=file

The issue report also notes an important boundary:

shorter clips from the same source may succeed,
direct-recorded Feishu videos can succeed via type=media,
longer iOS-library videos start failing consistently even when the file size is still under the configured media limit.

Fastest workaround

If you need the bot working again now, do not keep retrying the same long iOS photo-library upload.

Use one of these operator workarounds first:

resend the clip in a way Feishu classifies as video instead of file,
send a shorter clip if your tenant still accepts shorter photo-library videos,
send a link instead of the raw attachment, or
treat longer iOS photo-library videos as unsupported on this path until the channel is patched.

That is the shortest credible recovery path because it avoids the failing type=file download route entirely.

Cause

This does not look like a generic “Feishu is down” problem, and it does not look like a simple mediaMaxMb limit either.

The stronger explanation from the current evidence is a resource-type mismatch:

Feishu message metadata classifies the attachment as file,
OpenClaw then requests:

GET /open-apis/im/v1/messages/{message_id}/resources/{file_key}?type=file

but the download path appears to serve video-like content more reliably through type=media,
so the message metadata and the working download type disagree about what this resource really is.

That is why the failure pattern can look strangely selective:

same channel,
same tenant,
same bot,
only certain longer photo-library videos fail.

Confidence boundary: issue #49855 is strong evidence for the symptom, the failing type=file request, and the successful comparison against direct-recorded video uploads. The exact Feishu-side reason for the mismatch is still bounded inference, not confirmed vendor documentation.

Fix

1) If you maintain your own Feishu plugin build, add a bounded `type=media` fallback

The current issue points to a practical patch direction:

when metadata says file, but the attachment still looks video-like,
or when type=file returns a 5xx response,
retry the same resource through type=media.

A strong heuristic is to switch or retry when one of these is true:

the filename ends with .mp4, .mov, .m4v, or another obvious video extension,
the payload includes video-like metadata such as duration,
type=file fails with 502 or 504 on a resource that otherwise looks like a video.

Keep the boundary explicit:

this is a fallback for video-like file attachments,
not a blanket rule to download every Feishu file as media,
and not a claim that Feishu officially documents type=media as the right answer for all such uploads.

2) If you are not patching the plugin, treat this path as unsupported until fixed

For operators running stock OpenClaw, the safer rule today is:

longer iOS photo-library videos that arrive as file are not a dependable input path,
shorter clips may work, but that does not make the path trustworthy,
direct-recorded Feishu/Lark videos are a different path and may still work normally.

That framing is better than assuming the next retry, restart, or size tweak will make this class of uploads stable.

3) Do not chase the wrong fix first

These actions are less likely to fix this specific symptom on their own:

increasing mediaMaxMb when the failing file is already below the limit,
restarting the gateway without changing the upload path,
debugging general Feishu auth or app permissions when normal messages and shorter media already work.

If every attachment type is failing, or even direct-recorded videos fail the same way, you are probably dealing with a different Feishu problem.

Verify

After changing the workflow or patching the plugin, repeat a tight test loop:

Send one short video and one longer iOS photo-library video.
Check whether OpenClaw still calls the failing ?type=file path for the longer clip.
Confirm one of these outcomes:
- the sender used a safer upload path and the clip now processes normally,
- your patched build retries with type=media and the download succeeds, or
- you intentionally treat the long iOS-library upload as unsupported and stop routing that workflow through this path.
Confirm the gateway logs no longer show repeated 502 failures for that message.

A good verification result is not just “the bot replied once.” It is proving the long video no longer dies on the old resource path.

If you need to escalate upstream

Capture these artifacts before filing or updating an issue:

the message metadata block showing file_key, file_name, and any duration field,
the exact failing resource URL with ?type=file,
one successful comparison case, such as a shorter clip or a direct-recorded Feishu video,
OpenClaw version, tenant domain (feishu or lark), and platform.

That evidence makes it much easier to separate a true channel bug from a tenant-specific edge case.