Give the Store upload a timeout, and clear an abandoned submission (#52)

The first run of the Store stage, on 0.9.4, authenticated, found the
app, created the
submission, prepared the bundle, and then failed:

```
Uploading Bundle to Azure blob: 0%
Error while uploading the application package.
System.AggregateException: Retry failed after 6 tries.
  (The operation was cancelled because it exceeded the configured timeout of 0:00:00.)
```

## It is not a network fault

`msstore publish` takes `--uploadTimeout` in seconds and passes it
straight through:

```csharp
blobClientOptions.Retry.NetworkTimeout = TimeSpan.FromSeconds(uploadTimeout);
```

Unset, that is zero, so every attempt is cancelled the instant it starts
— six times, then
the aggregate. It failed identically on a developer machine, which is
what ruled out the
agent's network.

The option is missing from the Learn documentation and present in
`msstore publish --help`,
which is why it was missed when the stage was written. It applies per
attempt, so 900s is
deliberately generous for a package of around 100 MB rather than a tight
bound.

## The failure wedged the next attempt

It left a created-but-empty submission behind. Every later run would
then fail on the
guard against touching a pending submission — one failure disabling the
automation until
someone opened Partner Center, which is the thing this stage exists to
avoid.

The stage now deletes a submission whose status is `PendingCommit`:
created, never
committed, nothing in certification, nothing a person published. Every
other status still
fails the stage untouched, because an in-flight submission may be a
person's listing edit.
The status parsing was checked against live CLI output, escape codes and
all.

## The message that misled

The old failure text asserted that a pending submission was the usual
cause. It was wrong
here and cost real diagnosis time. It now points at the verbose output,
and `publish` runs
verbose so the next failure reports its own exception instead of one
swallowed line.

## What this does not do

0.9.4 was not submitted and will not be. A pipeline run uses the YAML on
`main` as of that
run, and `v0.9.4` cannot be released twice, so the next promoted release
is what exercises
this. Submitting 0.9.4 by hand would defeat the point.

Author: marcosqlbi

.azure/pipelines/build-whiteboard.yaml

@@ -398,6 +398,11 @@ stages:
   # Public: it is the address of the listing, apps.microsoft.com/detail/9NN5N0L2TMTF.
   - name: storeProductId
     value: '9NN5N0L2TMTF'
+  # Per upload attempt, and the package is around 100 MB, so this is generous rather than
+  # tight - a hung upload should still fail inside the job rather than run to the timeout
+  # of the job itself.
+  - name: storeUploadTimeoutSeconds
+    value: '900'
   jobs:
   - job: Submit
     displayName: Submit the released MSIX
@@ -464,13 +469,50 @@ stages:
         STORE_CLIENT_ID: $(StoreClientId)
         STORE_CLIENT_SECRET: $(StoreClientSecret)
 
+    # A failed submission leaves a created-but-empty submission behind, which would block
+    # every later attempt - the first failure wedges the automation until someone visits
+    # Partner Center. PendingCommit means exactly that: created, never committed, so no
+    # certification is running and nothing a person published is at stake. Anything else
+    # is left alone, because an in-flight submission may be someone's listing edit and a
+    # pipeline must not discard it.
+    - task: PowerShell@2
+      displayName: 'Clear an abandoned submission'
+      inputs:
+        targetType: 'inline'
+        pwsh: true
+        script: |
+          $ErrorActionPreference = 'Stop'
+          Set-StrictMode -Version Latest
+
+          # The CLI colours its output, so strip the escape sequences before matching.
+          $report = (msstore submission status $env:STORE_PRODUCT_ID 2>&1 | Out-String) -replace "`e\[[0-9;]*m", ''
+          Write-Host $report
+
+          if ($report -notmatch 'Found Pending Submission') {
+              Write-Host 'No pending submission. Nothing to clear.'
+              return
+          }
+
+          $status = if ($report -match 'Submission Status\s*=\s*(\w+)') { $Matches[1] } else { 'unknown' }
+          if ($status -ne 'PendingCommit') {
+              throw "A submission is pending with status '$status'. It is not an abandoned upload, so this stage will not delete it. Resolve it in Partner Center, then re-run this stage."
+          }
+
+          Write-Host 'Deleting an abandoned submission left by an earlier failed upload.'
+          msstore submission delete $env:STORE_PRODUCT_ID --no-confirm
+          if ($LASTEXITCODE -ne 0) { throw "msstore submission delete exited with $LASTEXITCODE" }
+      env:
+        STORE_PRODUCT_ID: $(storeProductId)
+
     # Packages only. The listing text, screenshots, and 'What's new' are carried over from
     # the last published submission untouched; changing them is 'msstore submission
     # updateMetadata' and a deliberate act, recorded in installer/msix/STORE-LISTING.md.
     #
-    # This fails if a submission is already pending for the product. That is correct: an
-    # in-flight submission may be someone's manual listing edit, and a pipeline must not
-    # discard it. Resolve it in Partner Center, then re-run this stage.
+    # -ut is not optional in practice. Unset, the CLI passes zero to
+    # BlobClientOptions.Retry.NetworkTimeout, so every upload attempt is cancelled the
+    # instant it starts and the whole publish fails with 'Retry failed after 6 tries' and
+    # a configured timeout of 0:00:00. The Learn documentation does not mention the option
+    # at all; 'msstore publish --help' does.
     - task: PowerShell@2
       displayName: 'Submit the package'
       inputs:
@@ -480,12 +522,13 @@ stages:
           $ErrorActionPreference = 'Stop'
           Set-StrictMode -Version Latest
 
-          msstore publish $env:MSIX_PATH -id $env:STORE_PRODUCT_ID
+          msstore publish $env:MSIX_PATH -id $env:STORE_PRODUCT_ID --uploadTimeout $env:UPLOAD_TIMEOUT --verbose
           if ($LASTEXITCODE -ne 0) {
-              throw "msstore publish exited with $LASTEXITCODE. A pending submission in Partner Center is the usual cause; the release itself is unaffected."
+              throw "msstore publish exited with $LASTEXITCODE. Read the verbose output above for the cause; the release itself is unaffected either way."
           }
 
           Write-Host 'Submitted. Certification takes hours to days and is tracked in Partner Center.'
       env:
         MSIX_PATH: $(MsixPath)
         STORE_PRODUCT_ID: $(storeProductId)
+        UPLOAD_TIMEOUT: $(storeUploadTimeoutSeconds)

TODO.md

@@ -55,14 +55,16 @@ visible and gates nothing.
 
 ## Waiting on the first automated Store submission
 
-Also not work. The pipeline's Store stage has never run. The only submission so far is the
-manual one for 0.9.2, and the stage was written against the documented behaviour of the
-Microsoft Store Developer CLI rather than against a run of it. The first promoted release
-after this lands is the one that proves it.
-
-0.9.4 is that release. `VersionPrefix` was bumped for it, because the Release stage
-refuses to reuse an existing tag and 0.9.3 could not be released a second time to carry
-the test.
+Also not work. The stage ran for the first time on 0.9.4 and failed: it authenticated,
+created the submission, and then could not upload the package, because `msstore publish`
+defaults its blob upload timeout to zero when `--uploadTimeout` is not given. That is
+fixed, but the fix has not been exercised — a pipeline run uses the YAML on `main` at the
+time it runs, and 0.9.4 cannot be released twice, so the next promoted release is the one
+that proves it.
+
+0.9.4 was not submitted to the Store. Nothing depends on the Store carrying every version,
+and the alternative was submitting it by hand, which is the thing this stage exists to
+avoid.
 
 Watch two things on that run. The stage has to pick the MSIX out of `drop-x64-true`, since
 both matrix jobs pack an identically named package and only one of them is self-contained.

docs/decisions.md

@@ -217,9 +217,10 @@ incomplete listing.
 
 Everything after it is the Store stage's job. It submits packages only — listing text,
 screenshots, and **What's new** carry over from the last published submission untouched.
-Changing them stays a deliberate act in Partner Center, recorded in `STORE-LISTING.md`, for
-the same reason the pipeline does not delete a pending submission to make room for its own:
-an in-flight submission may be a person's listing edit, and a pipeline must not discard it.
+Changing them stays a deliberate act in Partner Center, recorded in `STORE-LISTING.md`.
+The stage is equally careful with submissions it did not create: it deletes only one left
+`PendingCommit` by its own failed upload, because any other pending submission may be a
+person's listing edit and a pipeline must not discard it.
 
 The submission identity is not the signing one. The Partner Center account is associated
 with a different Microsoft Entra tenant than the one the pipeline signs in, so the two

docs/release-management.md

@@ -299,7 +299,14 @@ already published. Certification takes hours to days and gates nothing (decision
 
 `UseMSStoreCLI@0` installs the [Microsoft Store Developer CLI][msstore]; `msstore
 reconfigure` authenticates with the `SQLBI-StoreSubmission` group, and `msstore publish`
-uploads the package against Store product `9NN5N0L2TMTF`. Credentials are passed through
+uploads the package against Store product `9NN5N0L2TMTF`.
+
+**`--uploadTimeout` is not optional.** Left unset, the CLI passes zero to the blob
+client's `Retry.NetworkTimeout`, so every upload attempt is cancelled the instant it
+starts and the publish fails with `Retry failed after 6 tries` and a configured timeout of
+`0:00:00` — which reads like a network fault and is not one. The Learn documentation does
+not mention the option; `msstore publish --help` does. It is per attempt, so
+`storeUploadTimeoutSeconds` is set generously rather than tightly. Credentials are passed through
 the environment rather than the command line, because the agent echoes a native command
 line and log masking is a safety net rather than a guarantee.
 
@@ -317,9 +324,12 @@ Three things about it are deliberate:
   from the last published submission untouched. Changing them is `msstore submission
   updateMetadata` and stays a deliberate act in Partner Center, recorded in
   `installer/msix/STORE-LISTING.md`.
-- **It does not clear a pending submission.** If one is already in flight `msstore publish`
-  fails, which is correct: that submission may be a person's listing edit, and a pipeline
-  must not discard it. Resolve it in Partner Center and re-run the stage.
+- **It clears an abandoned submission, and only that.** A failed upload leaves a created
+  but empty submission behind, which would block every later attempt — one failure would
+  wedge the automation until someone visited Partner Center. Status `PendingCommit` means
+  exactly that case: created, never committed, nothing in certification. The stage deletes
+  it and continues. Every other status is left alone and fails the stage, because an
+  in-flight submission may be a person's listing edit and a pipeline must not discard it.
 
 The first submission was manual, on 20 August 2026 for 0.9.2, because the listing,
 screenshots, and age rating are one-time work no API performs — and holding the automation