[Bug]: opencli twitter download fail

[huangruisheng-yanzhonghuashu]

Description

opencli twitter download --tweet-url "https://x.com/WealthCode99978/status/2038102617826471940" --output ./twitter
[1/2] ✗ tweet_1.jpg
[2/2] ✗ tweet_2.jpg

Download complete: 2 failed in 208ms

twitter/download
┌───────┬───────┬────────┬──────────────┐
│ Index │ Type │ Status │ Size │
├───────┼───────┼────────┼──────────────┤
│ 1 │ image │ failed │ fetch failed │
├───────┼───────┼────────┼──────────────┤
│ 2 │ image │ failed │ fetch failed │
└───────┴───────┴────────┴──────────────┘

Steps to Reproduce

1. Run opencli ...
2. ...
3. See error

Expected Behavior

opencli twitter download success

OpenCLI Version

1.5.5

Node.js Version

20.x

Operating System

Windows

Logs / Screenshots

[Astro-Han]

Thanks for the report. I investigated this further and the failure does not appear to be in tweet parsing itself.

What is working:

• twitter download can extract valid pbs.twimg.com media URLs from the tweet.
• The media URL itself is reachable. The same image can be downloaded successfully outside the current downloader path.

Where it fails:

• The failure happens later, in the shared download layer used by twitter download.
• For some X image URLs, the current Node-side download path can fail with transport-level errors such as fetch failed, with underlying cases like ECONNRESET.
• In other words: the tweet URL is valid, the media URL is valid, but the current shared downloader is not fully robust for this class of X image responses.

I also prototyped a fallback-based fix locally, but I am not submitting it as-is because src/download/index.ts is core infrastructure and the safe version of this change needs stricter review of:

• proxy behavior
• redirect behavior
• cookie forwarding rules
• parity between the main fetch path and the fallback path

So the issue is real, the root cause is understood, but the final fix should be done carefully in the shared downloader rather than patched only in the Twitter adapter.

Recommended fix direction:

1. Keep the current fetchWithNodeNetwork() path as the primary path.
2. Add a narrowly-scoped fallback only for transport-level failures.
3. Make sure the fallback preserves existing proxy semantics, redirect handling, and cross-domain cookie stripping.
4. Add regression coverage for both request-stage failures and response-body-stream failures.

Leaving this open for a maintainer or a follow-up contributor to implement in the shared download layer with the required safety checks.