Skip to content

install-blobs, flash-self: handle a failing blob_status - #53

Merged
wardviaene merged 1 commit into
mainfrom
blob-status-errors
Nov 13, 2026
Merged

wardviaene merged 1 commit into
mainfrom
blob-status-errors

Conversation

@wardviaene

Copy link
Copy Markdown
Member

A pod on a dev build answered `blob_status` with "reply too large", and `flash-self` installed no blobs without saying so clearly.

  • `install-blobs` (and every `installBlobsList` caller): a failed slot listing is now a `blobStatusError` that says no blobs were installed and gives the pod's reason, and the command exits non-zero. `unknown cmd` still means firmware with built-in blobs.
  • `flash-self` (DFU and `--network`): the firmware is already flashed by then, so it prints a warning naming the skipped blobs from the manifest (for example `gw0, gw1, gw2, esp`) and the retry command `benchpod install-blobs`. It exits 0. Before, this was an error that did not name the blobs. A failure while installing the blobs is still an error.
  • README: both behaviors are documented.

Tests (fakes only, no hardware): `TestFlashSelfNetworkWarnsWhenBlobStatusFails`, `TestInstallBlobsAfterFlashWarnsWhenTheSlotsAreNotListed`, `TestInstallBlobsFailsWhenBlobStatusFails`, `TestInstallBlobsBuiltInIsNotABlobStatusFailure`. `go vet ./... && go test ./...` green.

🤖 Generated with Claude Code

…nstall"

install-blobs now fails when the pod does not list its blob slots, with the
pod's reason (a dev build answered "reply too large"). flash-self, whose
firmware is already in at that point, prints a warning naming the blobs it
skipped and the retry (`benchpod install-blobs`) instead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@wardviaene
wardviaene merged commit e95c111 into main Nov 13, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant