fix(feishu): fallback to original message_id for forwarded resource download

[luxuguang-leo]

What does this PR do?

When a user forwards a file or image in a Feishu group chat, the resource (file_key/image_key) belongs to the original message, not the forwarded copy. The download always fails because Feishu's message_resource.get API associates resources with the message they were first uploaded in.

This adds a fallback: when the initial download fails, resolve the source message_id via message.get API (checking root_id → parent_id → upper_message_id) and retry the download with it.

Both download paths are covered:

• Image (_download_feishu_image) — retries with resolved source message_id
• File/document (_download_feishu_message_resource) — same fallback

A shared helper _retry_with_forwarded_source prevents code duplication.

Changes Made

• adapter.py (+77 lines):

  • _resolve_forwarded_source_message_id() — calls message.get via _run_blocking(), extracts root_id → parent_id → upper_message_id as source
  • _retry_with_forwarded_source() — shared helper called from both download paths on failure
  • Wired into _download_feishu_image — retries with resolved source when initial download fails
  • Wired into _download_feishu_message_resource — retries with resolved source when all request types fail

• tests/gateway/test_feishu.py (+116 lines):

  • 6 unit tests for _resolve_forwarded_source_message_id (root_id, parent priority, no source, self-ref, API failure)
  • 4 integration tests for _retry_with_forwarded_source (image fallback, file fallback, no source, self-ref)

Review Comments Addressed

This PR fixes all three review points from the previous iteration:

#	Review	Status
1	Image path (_download_feishu_image) had no fallback — only file path did	✅ Both paths now have identical fallback via _retry_with_forwarded_source
2	Used asyncio.to_thread() instead of adapter's _run_blocking()	✅ Changed to await self._run_blocking(self._client.im.v1.message.get, request)
3	Missing E2E tests for full resolve → retry flow	✅ 10 new tests — 6 resolve + 4 retry (image + file + no-source + self-ref)

E2E Verification

Tested on a live Feishu group chat with require_mention: false:

1. Forwarded image → _download_feishu_image fails → fallback resolves source ID → retry succeeds → image cached locally ✅
2. Forwarded PDF → _download_feishu_message_resource fails → fallback resolves source ID → retry succeeds → PDF extracted and readable ✅
3. Directly sent image (non-forwarded) → downloads via normal path, no fallback involved ✅ (no regression)

All 10 unit/integration tests pass:

$ python3 -m pytest tests/gateway/test_feishu.py -q -k "forwarded or resolve_forwarded or retry_with"
..........                                                               [100%]
10 passed, 214 deselected in 3.24s

How to Test

python3 -m pytest tests/gateway/test_feishu.py -q -k "forwarded or resolve_forwarded or retry_with"

Checklist

• Bug fix (non-breaking change)
• Tests added — 10 new, all passing + E2E verified on live Feishu
• Commit follows Conventional Commits
• Tested on macOS 15.7.3

[teknium1]

Thanks for targeting a real missing fallback: current main returns empty values after resource-download failures in plugins/platforms/feishu/adapter.py:3893-3954.

Problems

• The new retry is only in _download_feishu_message_resource() (PR plugins/platforms/feishu/adapter.py:3818). Images use _download_feishu_image() from the normalized.image_keys loop (plugins/platforms/feishu/adapter.py:3784-3788 on current main), so forwarded images still cannot use the fallback described in the PR.
• The new message.get call uses asyncio.to_thread (PR plugins/platforms/feishu/adapter.py:3843). Use _run_blocking instead: commit b296915c82c9da02bd6edacf52490e68f85e1f16 moved Feishu SDK calls to the adapter-owned executor to prevent shared-executor shutdown failures.
• TestForwardedResourceFallback only tests helper return values (PR tests/gateway/test_feishu.py:4953-5045), not a failed initial download followed by a successful alternate-ID retry, nor the image path.

Suggested changes

• Share a bounded alternate-ID retry between file/media and image resource downloads, retain _run_blocking, and add behavior tests for both paths.

Automated hermes-sweeper review.

[teknium1]

This fallback is reachable only for normalized.media_refs; normalized.image_keys use _download_feishu_image() and still return on failure. Please apply the same bounded alternate-message retry to the image path or extract a shared helper, otherwise the PR's forwarded-image case remains broken.

[teknium1]

Please use await self._run_blocking(self._client.im.v1.message.get, request) here. Current main routes Feishu SDK calls through the adapter-owned executor after b296915 to avoid default-executor shutdown failures.

[teknium1]

Add an end-to-end downloader behavior test: make the initial resource request fail, resolve an alternate ID, and make the retry succeed. Cover both the message-resource and image download paths.

[luxuguang-leo]

@teknium1 This PR has been updated addressing all three review points. E2E verified on live Feishu — forwarded images and PDFs now download correctly. Would appreciate a re-review when you get a chance.