Repository navigation
fix(cloud): re-send a flow submit whose response was lost - #226
Merged
Merged
Conversation
When the API stalls, a `dcd cloud` submit can wait 300 s and then get a 502 from Railway's edge. The CLI can't tell whether the run was created, so it failed the command even when the run went ahead (dcd#1617). The API now answers a repeat of the same submit (same body, same upload id) with the run it already created, or a 409 while that run is still being created, and never creates a second run or charge. So the CLI sends a submit again while its outcome is unknown: - submitWithRetry (services/flow-submit.service.ts) re-sends the same body on a 409/500/502/503/504 or on any transport failure (network error, timeout, a body cut off), waiting 2 s and then up to 30 s between attempts, about three minutes in all. The flow zip is not uploaded again. - Each attempt has a 90 s timeout, well under the 300 s at which Railway's edge cuts it with a 502. - The multipart fallback for an API without the client-direct endpoint runs only when the first attempt 404s or 405s. A 404 after a retry comes from an API that took an earlier attempt. - `dcd cloud` prints one warning per retry (not in --json); dcd-mcp logs to stderr. Both record `submit_attempts` on the lifecycle telemetry event. - enhanceFetchError keeps the undici cause, so a timeout, a reset and a DNS failure no longer all read as "fetch failed". No new flags: `--retry` already means re-running failed tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
…empts Review on #226: - Every retry reused the auth resolved at the start of the command, and the retries can outlast a `dcd login` access token. The next attempt then got a non-retryable 401, possibly after an earlier attempt had already created the run. Each attempt now calls refreshAuth first, as the poll loops do. A session that can't be refreshed (definitive SessionRefreshError, or no stored session) is not retried. - `submit_attempts` was only recorded on success, so `command failed` never carried it. That is the worst-stall case it exists to measure. submitWithRetry now calls onAttempt before each attempt, and both `dcd cloud` and dcd-mcp record the count there. Also bounds the worst case. No attempt starts more than 5 minutes after the first. With every attempt timing out at 90 s the retries could otherwise hold the command for about 16 minutes; now the worst case is about 6.5. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. 🤖 Generated with Claude Code |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the API stalls, a
dcd cloudsubmit can wait 300 s and then get a 502 from Railway's edge. The CLI can't tell whether the run was created, so it failed the command even when the run went ahead (dcd#1617).The API now answers a repeat of the same submit (same body, same upload id) with the run it already created, or a 409 while that run is still being created, and never creates a second run or charge. So the CLI sends a submit again while its outcome is unknown:
dcd cloudprints one warning per retry (not in --json); dcd-mcp logs to stderr. Both recordsubmit_attemptson the lifecycle telemetry event.No new flags:
--retryalready means re-running failed tests.What & why
Type of change
fix— bug fixfeat— new featureperf— performance improvementrefactor— code change that's neither a fix nor a featuredocs— documentation onlychore/ci/build/test— tooling, no user-facing change!or PR notes aBREAKING CHANGE:)Checklist
pnpm lintpassespnpm typecheckpassespnpm buildpassesCHANGELOG.md(release-please handles this)README.md/STYLE_GUIDE.mdupdated if behaviour or output changedHow to test