From ea15fe2ffad098d9f853f67ccda02fa16b79988d Mon Sep 17 00:00:00 2001 From: Etienne Lescot Date: Wed, 19 Aug 2026 01:09:11 +0200 Subject: [PATCH 1/3] ci(store): make the CLI say why an upload failed --- .github/workflows/publish-msstore.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.github/workflows/publish-msstore.yml b/.github/workflows/publish-msstore.yml index 6f0d135c..af27675e 100644 --- a/.github/workflows/publish-msstore.yml +++ b/.github/workflows/publish-msstore.yml @@ -193,7 +193,10 @@ jobs: # `-i, --inputDirectory`, and rejects the `--inputFile` that Microsoft # Learn documents. The v1.9.5 dry run is what caught that. # Not $args: that is a PowerShell automatic variable. - $cmdArgs = @('publish', '.', '--inputDirectory', $pkg.Directory.FullName, '--appId', $env:PRODUCT_ID) + # -v is not decoration: without it the CLI reports upload failures as the + # bare line 'Error while uploading the application package.' with no status + # code, no URL and no body, which is what made v1.9.6 undiagnosable. + $cmdArgs = @('publish', '.', '--inputDirectory', $pkg.Directory.FullName, '--appId', $env:PRODUCT_ID, '-v') if ($env:DRY_RUN -eq 'true') { # Leaves the submission in draft instead of sending it to # certification: the only way to test this path without shipping. From 85dcd14e630392d5fa98e127e09801d744b7a175 Mon Sep 17 00:00:00 2001 From: Etienne Lescot Date: Wed, 19 Aug 2026 01:16:52 +0200 Subject: [PATCH 2/3] fix(store): pin msstore-cli, whose v0.4.0 cancels every upload instantly v1.9.6's Store submission failed three times in a row, always at the same place: submission created, bundle prepared, then "Uploading Bundle to Azure blob: 0%" and "Error while uploading the application package." ~22 s later. Same appx (335 MB, byte-for-byte the size that shipped for 1.9.5), same product, same command -- and the identical submission had succeeded on 2026-08-15. `-v` is what made it diagnosable, so it stays: Retry failed after 6 tries. The operation was cancelled because it exceeded the configured timeout of 0:00:00. Network timeout can be adjusted in ClientOptions.Retry.NetworkTimeout. NetworkTimeout is ZERO, so every request is cancelled the instant it starts; six instant retries is the whole 22 seconds. Nothing was ever sent, which is why there is no HTTP status anywhere in the failure. The variable is the CLI, not us: `microsoft/microsoft-store-apppublisher` defaults to `version: latest`, and msstore-cli v0.4.0 was published 2026-08-18T09:09Z -- the first release since v0.3.9 in January, and hours before the first failure. The 15 August success ran v0.3.9. So pin v0.3.9 in both places that configure the CLI: publish-msstore.yml and build.yml's publish-msstore job. Pinning one would have left the release path broken while the retry path worked, which is the confusing half-fix. --- .github/workflows/build.yml | 11 +++++++++++ .github/workflows/publish-msstore.yml | 11 +++++++++++ 2 files changed, 22 insertions(+) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 6925c8a6..f864b397 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -1128,6 +1128,17 @@ jobs: - name: Configure Microsoft Store CLI if: steps.store.outputs.enabled == 'true' uses: microsoft/microsoft-store-apppublisher@v1.1 + # PINNED, and it has to stay pinned. The action defaults to `latest`, and + # msstore-cli v0.4.0 (published 2026-08-18, the first release since v0.3.9 + # in January) ships an Azure SDK client whose `ClientOptions.Retry.NetworkTimeout` + # is 0:00:00 — every blob upload is cancelled the instant it starts. The CLI + # reports that as "Error while uploading the application package.", so the + # submission is created and configured and then dies at "Uploading Bundle to + # Azure blob: 0%", six instant retries later. v1.9.6 hit it three times in a + # row; the same package and account had submitted fine on v0.3.9 three days + # earlier. Unpin only against a CLI release that fixes the timeout. + with: + version: v0.3.9 - name: Submit the package to the Store id: submit diff --git a/.github/workflows/publish-msstore.yml b/.github/workflows/publish-msstore.yml index af27675e..cda0c31e 100644 --- a/.github/workflows/publish-msstore.yml +++ b/.github/workflows/publish-msstore.yml @@ -159,6 +159,17 @@ jobs: - name: Configure Microsoft Store CLI uses: microsoft/microsoft-store-apppublisher@v1.1 + # PINNED, and it has to stay pinned. The action defaults to `latest`, and + # msstore-cli v0.4.0 (published 2026-08-18, the first release since v0.3.9 + # in January) ships an Azure SDK client whose `ClientOptions.Retry.NetworkTimeout` + # is 0:00:00 — every blob upload is cancelled the instant it starts. The CLI + # reports that as "Error while uploading the application package.", so the + # submission is created and configured and then dies at "Uploading Bundle to + # Azure blob: 0%", six instant retries later. v1.9.6 hit it three times in a + # row; the same package and account had submitted fine on v0.3.9 three days + # earlier. Unpin only against a CLI release that fixes the timeout. + with: + version: v0.3.9 - name: Submit the package to the Store id: submit From 4c3da26bf10423683d27f283ab282fa9132087ef Mon Sep 17 00:00:00 2001 From: Etienne Lescot Date: Wed, 19 Aug 2026 09:43:23 +0200 Subject: [PATCH 3/3] ci(store): give the release path the same verbosity as the retry path CodeRabbit caught a half-fix, and it is exactly the one this PR's own commit message warns about for the pin: the CLI version got pinned in both call sites, but `-v` only went onto publish-msstore.yml. So the retry path would explain an upload failure and the RELEASE path -- the one that actually runs on a tag, and the one that failed for v1.9.6 -- would still print the bare "Error while uploading the application package." with nothing to act on. Both invocations now carry it. --- .github/workflows/build.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index f864b397..4d6ecbfb 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -1168,7 +1168,11 @@ jobs: # below, which takes the DIRECTORY holding it — the CLI's own usage # says `-i, --inputDirectory`, and rejects the `--inputFile` that # Microsoft Learn documents. The binary wins. - msstore publish . --inputDirectory $appx.Directory.FullName --appId $env:PRODUCT_ID + # -v for the same reason as the retry workflow: without it an upload + # failure is the bare line "Error while uploading the application package." + # with no status code, no URL and no body. This is the path a real release + # takes, so it is the path that most needs to be diagnosable. + msstore publish . --inputDirectory $appx.Directory.FullName --appId $env:PRODUCT_ID -v # Report what happened, not what was configured. Keyed off `enabled` alone # under always(), this claimed "Submitted to the Store" when `msstore