Intermittent send failures: fetch failed should surface as actionable error / retryable failure

[6rok]

Summary

wxclawbot send --text ... --json intermittently fails with:

{"ok":false,"error":"send failed: fetch failed"}

This happens even with a valid configured account and low send volume.

Environment

• package: @claw-lab/wxclawbot-cli
• observed on: 0.5.0
• account check passes:

wxclawbot accounts --json
# => [{"id":"...","configured":true,"baseUrl":"https://ilinkai.weixin.qq.com"}]

Repro

A simple text send sometimes works, sometimes fails:

wxclawbot send --text "hello" --json

Observed failure:

{"ok":false,"error":"send failed: fetch failed"}

Why this is a problem

For automation / cron usage, fetch failed is too opaque.

Right now the caller cannot tell whether this is:

• request timeout
• transient network failure
• upstream API reset / 5xx
• TLS/DNS/connectivity issue
• internal CLI bug / missing retry

This makes it hard to decide whether to retry, re-login, or fail fast.

Expected

It would help if the CLI did one or more of these:

1. Preserve the original error cause/details instead of collapsing to fetch failed
2. Distinguish retryable transport errors from API/business errors
3. Optionally support a small built-in retry for transient network failures
4. Return a more structured error shape in --json mode, e.g.
   • kind: transport_error | api_error | auth_error | rate_limit
   • retryable: true|false
   • cause: ...

Notes

This does not look like a user mistake:

• account is configured
• explicit --json is used
• low volume
• the same command can succeed and later fail with the opaque fetch failed

If helpful, I can also test a patched build.