feat: surface initError on the build when deploy fails - #71
Open
jonoirwinrsa wants to merge 6 commits into
Open
Conversation
When a deploy hits a terminal failure (e.g. capacity unavailable, init_failure), the backend now writes a user-facing message to the build's initError field synchronously. The CLI was polling the build status but discarding initError, so the user only saw "✗ Build failed with status: init_failure" with no actionable detail. This wires initError through buildStatusUpdateMsg → buildCompleteMsg → logDrainCompleteMsg and prints it after the failure line in both SimpleOutput and interactive modes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
wesrobin
reviewed
May 7, 2026
wesrobin
reviewed
May 7, 2026
No functional difference between nil and empty in this case, so the non-pointer type is simpler to work with. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both struct types share the same fields, so use Go's type conversion as the original code did rather than a struct literal (staticcheck S1016). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jonoirwinrsa
requested review from
Hkhan161
and removed request for
elijah-rou
August 11, 2026 20:37
The message is only carried by the poll → complete → drain messages and printed to scrollback, so a dropped field is invisible to the existing tests. Drive a failing build from GetBuild through to stdout in simple output mode, and pin that an empty initError prints nothing extra. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
wesrobin
approved these changes
Aug 12, 2026
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
2 participants
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.
Summary
When a deploy fails terminally (e.g. capacity unavailable,
init_failure), upstream writes a user-facing message tobuild.initError. The CLI was already polling build status but discardedinitError, so the user only saw✗ Build failed with status: init_failurewith no actionable detail.This adds
InitErrorto theAppBuildAPI type, threads it throughbuildStatusUpdateMsg → buildCompleteMsg → logDrainCompleteMsg, and prints it after the failure line in both SimpleOutput and interactive modes.Test plan
go build ./...go test ./internal/ui/commands/...TestDeployView_initErrorReachesOutputcovers the plumbing end to end: a failing build fetched fromGetBuildthrough to stdout in simple output mode, plus an emptyinitErrorprinting nothing extra. Verified both subtests fail when the field is dropped at either hop.--simpleand interactive modes.init_failure(e.g. crashing app) — verify nothing regresses; ifinitErroris not populated, only the existing failure line should print.Not covered by the tests: the
json:"initError"tag (the client is mocked, so no wire decoding happens) and the interactivetea.Printlnscrollback, whose text is not reachable fromView().🤖 Generated with Claude Code