Repository navigation
[wrangler] Workflow list and describe fail on transient API errors without retrying #15865
Description
What versions & operating system are you using?
Reproduced with unmodified Wrangler 4.138.0 and 4.140.0. The following output is from the standalone Wrangler 4.140.0 reproduction directory, using npx envinfo --system --npmPackages '{wrangler,create-cloudflare,miniflare,@cloudflare/*}' --binaries:
System:
OS: macOS 27.0
CPU: (10) arm64 Apple M1 Pro
Memory: 75.70 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 26.9.0 - /opt/homebrew/bin/node
Yarn: 1.22.22 - /opt/homebrew/bin/yarn
npm: 12.1.0 - /opt/homebrew/bin/npm
pnpm: 12.6.0 - /opt/homebrew/bin/pnpm
bun: 1.4.2 - /opt/homebrew/bin/bun
npmPackages:
wrangler: ^4.140.0 => 4.140.0
Please provide a link to a minimal reproduction
https://gist.github.com/alexminza/2c2e153837bc91d136c209588ddc65ae
Describe the Bug
wrangler workflows instances list --json and wrangler workflows instances describe --json exit after a single failed API request. A temporary HTTP 503 response or dropped connection aborts the read even when the next request would succeed. This makes multi-command Workflow inventory vulnerable to an isolated transient failure. This concerns HTTP retries in the management CLI, not retrying Workflow steps or restarting instances.
Expected: bounded retries for transient failures of these read-only requests, consistent with Wrangler's existing opt-in API retry handling. Persistent failures should still surface. This report does not request automatic retries for mutations.
Actual: both commands issue one request and exit with code 1. Healthy controls issue one request and exit with code 0.
Reproduction: save the single-file reproduction in an empty directory and run:
npm install --ignore-scripts --no-audit --no-fund wrangler@4.140.0
node --test wrangler-workflow-read-retries.mjsThe script runs the real CLI against a loopback HTTP fixture. For each command, it tests a healthy response, a first-request HTTP 503, and a first-request connection drop. The two failure fixtures would return a successful response on the next request. Each child process receives a scrubbed environment, synthetic credentials and an isolated configuration with .env loading disabled. No Cloudflare account, deployment, Worker or Miniflare Workflow execution is involved.
Both tested versions produce two passing healthy controls and four failing recovery assertions, exiting normally with code 1. This isolates missing read retries; it does not identify the cause of any real Cloudflare outage or connection failure.
Source analysis: the pinned Wrangler 4.140.0 describe command calls fetchResult directly, and the list command calls fetchCursorPage directly. Their Wrangler fetch wrappers delegate to the shared fetch implementation without applying the existing retryOnAPIFailure helper.
Related reports: #6913 concerns deployment reliability; its maintainer discussion notes that retry coverage depends on the endpoint. The merged #6801 changes deployment upload retries, not these Workflow reads. The merged #14877 extends the opt-in helper's handling of HTTP 429 and Retry-After; it does not make these commands use that helper. These reports provide related retry context, not a verified fix for this path.
Please provide any relevant error logs
Sanitized diagnostic output from the Wrangler 4.140.0 run:
{"version":"4.140.0","action":"describe","failure":"none","calls":1,"exitCode":0}
{"version":"4.140.0","action":"describe","failure":"503","calls":1,"exitCode":1}
{"version":"4.140.0","action":"describe","failure":"disconnect","calls":1,"exitCode":1}
{"version":"4.140.0","action":"list","failure":"none","calls":1,"exitCode":0}
{"version":"4.140.0","action":"list","failure":"503","calls":1,"exitCode":1}
{"version":"4.140.0","action":"list","failure":"disconnect","calls":1,"exitCode":1}
tests 6
pass 2
fail 4
cancelled 0
skipped 0
Activity
workers-devprod commentedon Sep 25, 2026
Automated triage
Issue assessment
package:wrangler(high)product:workflows(high)package:workers-utils(medium)Actionability and missing information
Wrangler 4.138.0/4.140.0: workflows instances list --json and describe --json send one API request and exit 1 on a first-request 503 or dropped connection per a loopback-fixture test; the report asks for bounded retries on these read-only commands using the existing opt-in retry helper.
Reproduction reason: The report provides a single-file test script and exact commands that run wrangler against a local loopback fixture with a scrubbed environment and synthetic credentials, so the reported single-request failure behavior can be verified without cloud resources.
Reproduction
Evidence and attempted steps
Blocker: Automated reproduction failed before recording a result.
Agent outcome: Failed.
Failure type:
submission_timeoutFailure: Submission exceeded the configured timeout.
Details: The operation ran longer than the configured durability timeout.
Submission ID:
sub_ik_32f847cdd8ef25f5800652b9d079cc3cThis summary was generated by an LLM and may contain errors. Please verify its findings.
Triage bot commands and options
Repository collaborators with write or admin access can trigger actions by commenting on this issue:
@workers-devprod reproduce: Attempt to reproduce the issue using its description and recent comments.tw4 commentedon Sep 25, 2026
I'd like to pick this one up. My plan is to wrap the read-only requests in
workflows instances list(fetchCursorPage) andworkflows instances describe(fetchResult) with the existingretryOnAPIFailurehelper. That also covers the--id latestlookup ingetInstanceIdFromArgs, since it's the first requestdescribemakes by default. Mutating requests stay as they are. I'll add unit tests for a first-request 503, a dropped connection, and a persistent failure that still surfaces after the retries run out. I'll open a PR shortly.dario-piotrowicz commentedon Oct 1, 2026
Thanks for the issue @alexminza 🙂
And thanks @tw4 for the PR, I gave it a review, please have a look 🙏