← Back to issue list

fix(store): raise error when upload processing status is 'error'

View original Github issue

Metadata

Project
snapcraft
Number
#6310
Type
pull request
State
open
Author
Tejas-Raj01
Labels
—
Created
Updated
Closed
—

Current evaluation

Adds an explicit `status.get("code") == "error"` check to StoreClientCLI.notify_upload so `snapcraft upload --release` raises SnapcraftError instead of falsely printing a revision/released message, plus a unit test. Fixes #6299.

Suggested action: needs review

Reason: Diff is tiny (+41/-1, 3 files) and every relevant check is green — 'lint / files', 'test / Fast tests (ubuntu-24.04)', 'test / Slow tests', 'test / Minimum dependencies' all pass; the only failure is integration-spread-tests (google:ubuntu-26.04-64), which the author attributes to runner infrastructure and which does not exercise this store polling path. It is still awaiting a maintainer: 0 reviewers, no approval, and the last two comments (2026-06-27, 2026-07-21) are the author pinging @mr-cal, not review feedback. One substantive concern should be resolved before merge: the strict equality `code == "error"` may not match the code actually observed in #6299, whose CLI output was "Status: error while processing", which in this repo is the _HUMAN_STATUS mapping for `processing_error` (snapcraft/store/client.py:51) — so the fix as written may not cover the reported reproduction, and the empty-errors error message is untested for content.

Evaluated by: mr-cal-bot

Impact: 45 Quick Win: 19 Complexity: 15 Confidence: 72 Actionability: 50

Issue body

**Context:** Currently, when running `snapcraft upload --release`, the CLI polls the store API for the upload processing status. If the store's automated review fails, the API sometimes returns a status with `code: "error"` but an empty `errors` list. Because the existing logic only raised an exception if the `errors` list was populated, the CLI silently bypassed the error, broke out of the polling loop, and returned a revision number—falsely reporting a successful release to the user when it was actually rejected. **Changes in this PR:** - Updated the `notify_upload` method in `snapcraft/store/client.py` to explicitly check if `status.get("code") == "error"`. If this condition is met, the CLI now properly aborts the process and raises a `SnapcraftError`. - Added a corresponding unit test `test_notify_upload_error_status_raises_error` in `tests/unit/store/test_client.py` to ensure regressions are prevented. Fixes #6299 --- - [x] I've followed the contribution guidelines. - [x] I've signed the CLA. - [x] I've successfully run `make lint && make test`.

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha
Impact: 45
Quick Win: 19
Complexity: 15
Confidence: 72
Actionability: 50
needs review Adds an explicit `status.get("code") == "error"` check to StoreClientCLI.notify_upload so `snapcraft upload --release` raises SnapcraftError instead of falsely printing a revision/released message, plus a unit test. Fixes #6299.
stealth/space-bunny-alpha
Impact: 48
Quick Win: 27
Complexity: 18
Confidence: 82
Actionability: 68
needs review Adds a check in StoreClientCLI.notify_upload for status code "error" so `snapcraft upload --release` raises SnapcraftError instead of reporting a false success; plus a unit test. Awaiting review, all unit/lint CI green.
stealth/space-bunny-alpha
Impact: 58
Quick Win: 27
Complexity: 18
Confidence: 89
Actionability: 56
needs review Adds an error-status check to store upload polling and a regression test, preventing false success reports for upload --release. Review is pending; one Ubuntu 26.04 spread test fails.
qwen3.6-35b-a3b-mtp-q6
Impact: 55
Quick Win: 47
Staleness: 65
Complexity: 15
Confidence: 80
needs review Fixes snapcraft upload --release silently reporting success when store review fails by checking status code 'error' in notify_upload. Waiting for maintainer review for 72 days.
qwen3.6-35b-a3b-mtp-q6
Impact: 55
Quick Win: 47
Staleness: 50
Complexity: 15
Confidence: 70
needs review Fixes snapcraft upload --release falsely reporting success when store review fails by checking status code in notify_upload. Waiting for maintainer review.
qwen3.6-35b-a3b-mtp-q6
Staleness: 5
Complexity: 15
Confidence: 95
needs review Fixes silent success bug during snapcraft upload when store API returns error code with empty errors list. Adds explicit status check and unit test. Awaiting maintainer review.
qwen/qwen3.6-35b-a3b
Staleness: 15
Complexity: 15
Confidence: 90
needs review Fixes a bug where snapcraft upload silently succeeds when the store API returns an error code with an empty error list. Adds explicit error handling and a unit test. Currently awaiting maintainer review.
qwen3.6-35b-a3b-mtp-q6
Staleness: 40
Complexity: 10
Confidence: 90
needs review Fixes silent success bug during snapcraft upload when store API returns error code with empty errors list. Adds explicit error check and unit test. Awaiting maintainer review after 13 days of inactivity.

Update history

Date Change
updated
updated
updated
updated
updated
updated

Related work

  • Likely Fixed By: canonical/snapcraft#6299 (confidence 90%)

    PR body states 'Fixes #6299'; the issue (open, no maintainer response) reports upload --release printing 'Revision N created ... and released to ...' despite a failed store review.

  • Related To: snapcraft (launchpad)#1743587 (confidence 45%)

    Related launchpad report that a snap needing manual review is reported as a successful push; relevant because the new `code == "error"` check does not cover the `need_manual_review` code already present in _HUMAN_STATUS.

Related issues

Issue Project State Summary Similarity
#4863 fix(cli): properly capture store errors snapcraft merged Merged #4863 in commit 426df7ec3, restoring legacy-style store-error capture so store failures are no longer reported as Snapcraft internal errors.
73%