ci(windows): pin msstore CLI to v0.4.2 now that #162 is fixed

[azchohfi]

The pin sat on v0.4.1, the last release carrying microsoft/msstore-cli#162. That is fixed by #163 and released in v0.4.2 on 2026-09-02 — the exact condition docs/WINDOWS-STORE-MSIX.md set for advancing the pin:

advance that pin only after validating a released version containing microsoft/msstore-cli#163.

This is deliberately not a revert of #5345

#5345 was mostly Qt symbol packaging — stage-debug-symbols.ps1, check-symbol-package.ps1, the .appxsym topology work. Only one of its five commits (ae57707) was the timeout workaround, and only the pin and its surrounding prose change here.

-UploadTimeoutSeconds 300 stays — and it matters here

This one is not just habit. AzureBlobManager calls blobClient.UploadAsync without setting StorageTransferOptions, so the SDK's default 256 MiB InitialTransferSize applies and a .msixupload under that size is sent as a single PUT. Retry.NetworkTimeout therefore has to cover the entire transfer, not one chunk.

Your published .msixupload is ~197 MB (v26.9.1), and #5345 adds symbols on top. At the CLI's restored 100 s default that would demand a sustained ~2 MB/s for the whole request — genuinely tight, and it would fail in exactly the same Uploading Bundle to Azure blob: 0% shape as #162 did, which would be a miserable thing to re-diagnose.

So the 300 s value is kept and re-documented as a deliberate sizing decision rather than a bug workaround.

Net effect

• version: v0.4.1 → v0.4.2
• docs/WINDOWS-STORE-MSIX.md: the timeout paragraph rewritten, plus the v0.4.1 mention in the numbered flow
• publish-store.ps1: .PARAMETER UploadTimeoutSeconds help rewritten

No behaviour change beyond the version bump. The note about keeping verbose logging off in public Actions logs is preserved verbatim.

Sent as part of a sweep across the repos that referenced msstore-cli#162.

[jensenpat]

Manually reviewed and approved. Moving MS Store pipeline to 0.4.2 to address file size limit stall from last week's release. No changes to debug symbols or upload timer. Thanks Alexandre @azchohfi.

[aethersdr-agent]

Issue fit

No linked AetherSDR issue — the PR is scoped against upstream microsoft/msstore-cli#162 / #163 and against the pin that #5345 landed. That's fine: GOVERNANCE.md exempts plain build/CI fixes from the RFC route, and this is one. Against its own stated intent it does exactly what it says — one pin bump plus prose that stops describing a regression as live. I confirmed the pin history: e642458c (#5345) is what introduced version: v0.4.1 and the --uploadTimeout 300 workaround wording, so the "PR that made the claim" and "PR that retires it" line up.

Scope

File	What it changes	Claimed by title/body?	Verdict
.github/workflows/windows-installer.yml	One line: version: v0.4.1 → v0.4.2. Action SHA pin cc9910a8…, the if: guards, secrets env and the publish-store.ps1 invocation are all untouched.	Yes	In scope
docs/WINDOWS-STORE-MSIX.md	§"Automated Store Submission": CLI version in step 2, and the timeout paragraph split into "the bug is fixed" + "300 s is a deliberate value" + the verbose-logging/pinning rationale.	Yes	In scope
packaging/windows/publish-store.ps1	Comment-only. I diffed the executable body: param(), [ValidateRange(100, 100000)], the default 300, the glob/one-package logic and $publishArgs are byte-identical.	Yes	In scope, and the "no behaviour change" claim holds

No CHANGELOG entry added — correct for this repo. No stale v0.4.1 left anywhere: grep -rn "msstore\|apppublisher" over the tree finds only docs/WINDOWS-STORE-MSIX.md:238 (updated) and the historical CHANGELOG rows, which are release records and correctly left alone. Nothing in the diff is unexplained.

Blockers

None.

Nits (non-blocking)

• The load-bearing facts are upstream and I could not verify any of them from here. v0.4.2 existing, it containing #163, and 100 s being the resulting default are all assertions about a repo I have no network access to (api.github.com is blocked in this environment). You are the upstream maintainer, which is about as good as provenance gets, but the PR body carries no artifact — a link to the v0.4.2 release, or the msstore --version line from a run, would turn three claims into evidence. See inline on docs/WINDOWS-STORE-MSIX.md:268.
• The deleted sentence was a forward-looking instruction, and its replacement isn't. The old text ended "advance that pin only after validating a released version containing microsoft/msstore-cli#163." That's the rule for the next bump too, and the new closing paragraph only says the CLI stays pinned. Suggest keeping one clause about validating before advancing. Inline on docs/WINDOWS-STORE-MSIX.md:280-281.
• First exercise of the new pin is a live v* tag. The Store block is dormant until AETHERSDR_STORE_PRODUCT_ID is set, so no CI lane touches this path — the three green checks on f2446d80 (build, check-macos, check-windows) prove nothing about it either way. Worth knowing the blast radius if version: v0.4.2 fails to resolve: the setup step is not continue-on-error, and it runs after the softprops release step at ~line 424, so a bad value reddens a run whose release assets are already published. That shape is pre-existing (#5345), not introduced here.
• The 256 MiB single-PUT reasoning holds only while the package stays under that threshold; past it the timeout becomes per-chunk and 300 s is merely generous. No action needed — noting it so nobody later reads the paragraph as a size-independent rule.

What I tried to break

• "Only the version pin and the surrounding prose change; no behaviour change." Checked by reading the full post-merge publish-store.ps1, not just the hunk: the --uploadTimeout argument is still built from $UploadTimeoutSeconds with InvariantCulture, the default is still 300, the ValidateRange(100, …) floor still matches the "100 s default" story, and --noCommit is intact. The change really is a comment. Held.
• Looked for a stale sibling. Grepped the whole tree for msstore, apppublisher, 0.4.0/0.4.1/0.4.2 and uploadTimeout. The only other version mention is step 2 of the doc, which the diff updates in the same commit. No second workflow, no second script, no docs page left describing v0.4.1. Held.
• Read the - lines for a removed guard. The only deletion with teeth is the "advance that pin only after validating…" sentence — reported above as a nit, not a regression, since the PR is the validated advance rather than a removal of the gate.
• Checked whether the removed workaround framing weakens anything operationally. It doesn't: --uploadTimeout 300 is still passed unconditionally, so even if v0.4.2's default were still broken the workflow would be unaffected. That's the property that keeps this bump low-risk.
• Could not check: that v0.4.2 exists, that the pinned action SHA resolves an arbitrary newer CLI tag, that --uploadTimeout kept its spelling in v0.4.2, and that ~200 MB matches the current .msixupload. All network- or artifact-dependent. Everything above is reasoned from the diff and the checkout at /tmp/aetherclaude/pr-5388, not reproduced at runtime.

No test changes, and none are warranted — there is no seam here; a CTest cannot assert an upstream release tag exists. No socket-owning tests are added, modified or removed by this PR.

Recommendation

Approve with nits. The diff is minimal, internally consistent, and safe by construction — --uploadTimeout 300 is still passed explicitly, so the bump cannot reintroduce the #162 failure mode even if the upstream fix were incomplete. Next step: add the v0.4.2 release link (or a msstore --version line) to the PR body so the pin advance carries its own evidence, and consider keeping a "validate before advancing" clause in the doc. Thanks for retiring the workaround framing rather than leaving the docs describing a bug that no longer exists — and for splitting out why 300 s survives the fix; that paragraph is the useful part of this change.

One more thing: commit signing

main here requires verified signatures, so this will be blocked at merge until the one commit on this branch is signed. Quickest setup (SSH key signing, no GPG needed):

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

(If you have no SSH key yet: ssh-keygen -t ed25519 first.) Then on GitHub: Settings → SSH and GPG keys → New SSH key → set the key type dropdown to Signing Key → paste the .pub.

Re-sign what's already on the branch:

git rebase main --exec "git commit --amend --no-edit -n -S"
git push --force-with-lease

Full docs, including GPG and troubleshooting: https://docs.github.com/authentication/managing-commit-signature-verification
[{"path": ".github/workflows/windows-installer.yml", "line": 450, "body": "The action SHA pin (cc9910a8…) is unchanged while the CLI version it resolves moves forward. That's the right split, but it does assume this action revision fetches the release by tag rather than carrying a build-time version list — I can't verify that from here (no network to github.com in this environment).\n\nWorth knowing the failure shape if v0.4.2 doesn't resolve: this step has no continue-on-error, and it runs after the softprops release step above, so the run goes red with the release assets already published. Pre-existing structure from #5345, not something this PR introduces — just naming it since this bump is the first thing to exercise the new value, and it will do so on a live v* tag."}, {"path": "docs/WINDOWS-STORE-MSIX.md", "line": 268, "body": "Three upstream claims land in this sentence and the next: that v0.4.2 exists, that it carries #163, and that the resulting default is 100 s. I could not check any of them — this environment has no access to github.com/api.github.com, so I'm taking them on your authorship rather than on evidence.\n\nOne link to the v0.4.2 release (or the msstore --version output from a run with the new pin) in the PR body would settle all three and give a future reader of this doc something to check against. Not blocking — the workflow still passes --uploadTimeout 300 explicitly, so nothing here is load-bearing for correctness, only for the doc's accuracy."}, {"path": "docs/WINDOWS-STORE-MSIX.md", "start_line": 280, "line": 281, "body": "The sentence this replaces ended with an instruction for the next maintainer, not just a statement about today:\n\n> advance that pin only after validating a released version containing microsoft/msstore-cli#163.\n\nThe #163-specific half is rightly retired, but "validate a release before advancing the pin" is a standing rule that this PR is itself an instance of, and it's now gone from the doc. Suggest keeping it in general form:\n\nsuggestion\nThe CLI stays pinned to prevent `latest` from silently changing publish\nbehavior; validate a release before advancing the pin.\n"}]

---

_{🤖 aethersdr-agent · cost: $5.0643 · model: claude-opus-5}

[ten9876]

Issue fit

No linked AetherSDR issue, and none is needed — GOVERNANCE.md routes architectural changes through an RFC and exempts plain build/CI fixes, which this is. Against its own stated intent the diff does exactly what it claims: advance one pinned version and retire the prose that described a now-fixed upstream regression as live.

A previous automated pass on this PR flagged the upstream facts as unverifiable (no network in that environment) and its inline comments failed to attach. This review verified all of them against the upstream repo, and they hold:

Claim in the PR body	Verified
v0.4.2 exists	Yes — released 2026-09-02T03:40Z
It contains msstore-cli#163	Yes — ffb1aaf7 "Fix --uploadTimeout defaulting to 0 when the option is omitted (#163)" is in v0.4.1...v0.4.2
The restored default is 100 s	Yes — PublishCommand.cs:24 at tag v0.4.2: internal const long DefaultUploadTimeoutSeconds = 100;, wired via the new DefaultValueFactory on line 115
No StorageTransferOptions, so it is a single PUT	Yes — AzureBlobManager.cs:40 calls blobClient.UploadAsync(fileStream, blobUploadOptions, ct) with the timeout applied at line 28 as blobClientOptions.Retry.NetworkTimeout
The package is ~200 MB	Yes — AetherSDR-26.9.1.0-Windows-x64.msixupload on the v26.9.1 release is 197 MB

The ValidateRange(100, 100000) floor in publish-store.ps1 also matches upstream's MinUploadTimeoutSeconds/MaxUploadTimeoutSeconds exactly, so the doc's "100 s default" story is internally consistent with the script's own guard. The reasoning for keeping -UploadTimeoutSeconds 300 is sound and correctly reframed from workaround to sizing decision.

Scope

File	What it changes	Claimed by title/body?	Verdict
.github/workflows/windows-installer.yml	One line: version: v0.4.1 → v0.4.2. The action SHA pin cc9910a8…, both if: guards, the secrets env and the publish-store.ps1 invocation are untouched.	Yes	In scope
docs/WINDOWS-STORE-MSIX.md	CLI version in step 2 of the numbered flow, and the timeout paragraph split into "the bug is fixed" / "300 s is a deliberate size-driven value" / verbose-logging + pinning rationale.	Yes	In scope
packaging/windows/publish-store.ps1	Comment-only — the .PARAMETER UploadTimeoutSeconds help text. param(), the ValidateRange, the 300 default, the glob logic and $publishArgs are byte-identical.	Yes	In scope; the "no behaviour change" claim holds

No CHANGELOG entry — correct for this repo (it is a release-prep file). The body's own claims check out against the diff. Nothing here is unexplained.

Blockers

None in the code. One merge-mechanical blocker, below.

The one commit on this branch is unsigned

main has required_signatures enabled, so f2446d80 will be refused at merge regardless of the approval and green checks. This is the only thing standing between this PR and merge — the review verdict itself is positive.

Quickest path (SSH key signing — no GPG, reuses the key you already push with):

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

If you have no SSH key yet, ssh-keygen -t ed25519 -C "alzollin@microsoft.com" first. Then on GitHub: Settings → SSH and GPG keys → New SSH key, set the Key type dropdown to Signing Key (a key registered only as an Authentication Key will not verify), and paste the contents of the .pub file.

Re-sign the commit already on the branch:

git checkout bump-msstore-cli-v0.4.2
git commit --amend --no-edit -S
git push --force-with-lease

Then confirm — GitHub should show a green Verified badge on the commit:

gh api repos/aethersdr/AetherSDR/pulls/5388/commits \
  -q '.[] | "\(.sha[0:8]) \(.commit.verification.verified) \(.commit.verification.reason)"'

Two things to watch for. The commit is co-authored with Copilot App, and --amend preserves trailers, so the Co-authored-by: line survives — no need to re-add it. And the signing email must be one verified on your GitHub account or the badge reads unverified rather than verified; alzollin@microsoft.com is what is on the commit now, so make sure that address is in Settings → Emails. Full reference, including the GPG route: https://docs.github.com/authentication/managing-commit-signature-verification

Note that the force-push will dismiss @jensenpat's approval — branch protection has dismiss_stale_reviews on. That is expected; it will need a re-approve afterwards.

Nits (non-blocking)

1. The removed sentence carried a forward-looking rule. The old prose ended "advance that pin only after validating a released version containing microsoft/msstore-cli#163." The #163-specific half is rightly retired, but "validate before advancing" is a standing instruction for the next bump, and it is now gone. Suggestion inline on docs/WINDOWS-STORE-MSIX.md:280-281.

2. A stale sibling reference the diff does not reach. docs/WINDOWS-STORE-MSIX.md:207, in the earlier "GitHub Actions" walkthrough, still says microsoft/microsoft-store-apppublisher@v1.1 — but the workflow pins the action by SHA (cc9910a8…) and the CLI by version:. Since you are already updating the parallel numbered flow at line 238, folding this line in would leave the doc with one story. Pre-existing, not introduced here.

3. The 256 MiB reasoning is size-dependent. Above that threshold the SDK chunks and the timeout becomes per-chunk, at which point 300 s is merely generous rather than necessary. Worth not reading the new paragraph as a size-independent rule later; no change needed at 197 MB.

4. First exercise of the new pin is a live v* tag. The Store block is dormant until AETHERSDR_STORE_PRODUCT_ID is set, so the three green checks say nothing about this path either way, and the setup step has no continue-on-error and runs after the softprops release step — a bad version: would redden a run whose release assets are already published. Structure is pre-existing from #5345; noting the blast radius since this bump is what first exercises it.

What was verified vs. read

Verified empirically against the upstream repository at tag v0.4.2 (source read at that ref, not at main): the release's existence and date, #163's presence in the tag, the 100 s default constant and its DefaultValueFactory wiring, the absence of StorageTransferOptions on the upload call, and the min/max range. Verified against this repo: the 197 MB .msixupload, that publish-store.ps1's executable body is unchanged, and that no other file in the tree still names v0.4.1. Read only: that the pinned action revision resolves the CLI by tag at runtime — its action.yml takes version as a free-form input defaulting to latest and the resolution happens inside the bundled dist/index.js, which I did not audit.

No tests, and none are warranted — there is no seam here; a CTest cannot assert that an upstream release tag exists.

Recommendation

Approve with nits, blocked only on signing. The change is minimal, every load-bearing claim is now backed by upstream evidence rather than authorship, and it is safe by construction: --uploadTimeout 300 is still passed unconditionally, so the bump cannot reintroduce the #162 failure mode even had the upstream fix been incomplete. Sign the commit and force-push; approval will need re-applying afterwards.

Thanks for retiring the workaround framing rather than leaving the docs describing a bug that no longer exists — and for separating out why 300 s survives the fix. That paragraph is the durable part of this change.

[ten9876]

Verified all three claims in this sentence against the upstream repo at tag v0.4.2, so this reads accurately:

• v0.4.2 released 2026-09-02T03:40Z.
• ffb1aaf7 — "Fix --uploadTimeout defaulting to 0 when the option is omitted (NR2 is not working in the version 0.5.5. (Mac OS Precompiled) When enabled from the Slice -> DSP -> NR2  #163)" — is in the v0.4.1...v0.4.2 range.
• MSStore.CLI/Commands/PublishCommand.cs:24 at that tag: internal const long DefaultUploadTimeoutSeconds = 100;, now actually reached via the DefaultValueFactory added on line 115.

Worth noting for anyone re-reading this later: the fix's own source comment spells out the precondition — the option's arity is ExactlyOne, so an omitted option is served by the factory without reaching the CustomParser at all. That is what makes "omitting the option would correctly yield the documented 100 s default" true, and it would stop being true if the arity were ever relaxed. Nothing to change here.

[ten9876]

The sentence this replaces ended with an instruction aimed at the next maintainer, not just a statement about today:

advance that pin only after validating a released version containing microsoft/msstore-cli#163.

Retiring the #163-specific half is right. But "validate a release before advancing the pin" is a standing rule that this PR is itself a clean instance of, and it has gone from the doc along with it. Suggest keeping it in general form:

Suggested change

	The CLI stays pinned to prevent `latest` from silently changing publish
	behavior.
	The CLI stays pinned to prevent `latest` from silently changing publish
	behavior; validate a release before advancing the pin.

Non-blocking.

[ten9876]

Both halves of this check out: AzureBlobManager.cs:40 at v0.4.2 calls blobClient.UploadAsync(fileStream, blobUploadOptions, ct) with no StorageTransferOptions, and line 28 applies the value as blobClientOptions.Retry.NetworkTimeout — so the timeout does cover the whole request. And "~200 MB" is accurate: AetherSDR-26.9.1.0-Windows-x64.msixupload on the v26.9.1 release is 197 MB.

One caveat for future readers rather than for this PR: the single-PUT property holds only while the package stays under the SDK's 256 MiB InitialTransferSize. Past that it chunks and the timeout becomes per-chunk, at which point 300 s is generous rather than necessary. Fine at 197 MB — just not a size-independent rule.

[ten9876]

Right split — the action stays pinned by SHA while only the CLI version it fetches moves. I confirmed the action's action.yml at cc9910a8 takes version as a free-form input (defaulting to latest), so an arbitrary newer tag is plausible; the actual resolution happens in the bundled dist/index.js, which I did not audit, so that last step is read rather than verified.

Blast radius if v0.4.2 ever failed to resolve: this step has no continue-on-error and runs after the softprops release step above, so the run would go red with the release assets already published. Pre-existing structure from #5345, not introduced here — naming it because this bump is the first thing to exercise the new value, and it will do so on a live v* tag with no CI lane ahead of it.

[azchohfi]

Force-push: signature only, content unchanged

main requires verified signatures and my original commit was unsigned, so I re-signed and force-pushed. Flagging it explicitly so this doesn't read as a silent rewrite:

	Before	After
Commit	f2446d80	c5b9daab
Tree	747a0c6bc872c6cfe010fd713074b1b819b335e7	747a0c6bc872c6cfe010fd713074b1b819b335e7
Signature	unsigned	verified=true / valid

The tree hashes are identical — the diff @jensenpat approved is byte-for-byte the diff that is here now. The only change is the signature header; the Co-authored-by trailer survived the amend.

Sorry for the churn @jensenpat — branch protection has dismiss_stale_reviews on, so this dropped your approval and it needs re-applying.

Evidence for the upstream claims

@aethersdr-agent asked for an artifact rather than taking the upstream facts on authorship; @ten9876 independently verified them. For the record, so a future reader of the doc has something to check against:

• v0.4.2 release: https://github.com/microsoft/msstore-cli/releases/tag/v0.4.2 — published 2026-09-02T03:40:06Z
• NR2 is not working in the version 0.5.5. (Mac OS Precompiled) When enabled from the Slice -> DSP -> NR2  #163 is in it: the release notes list ffb1aaf7664f3b8e730349cfec04c450c5957ab8 — "Fix --uploadTimeout defaulting to 0 when the option is omitted (NR2 is not working in the version 0.5.5. (Mac OS Precompiled) When enabled from the Slice -> DSP -> NR2  #163) [ Tx Band Settings from the Settings Menu doesn't open the Tx Band Settings Window #162 ]"
• The restored default is 100 s: PublishCommand.cs at v0.4.2 defines DefaultUploadTimeoutSeconds = 100, now wired through a DefaultValueFactory alongside the existing CustomParser — which is precisely the missing piece that caused Tx Band Settings from the Settings Menu doesn't open the Tx Band Settings Window #162.
• Single PUT: AzureBlobManager.UploadFileAsync calls blobClient.UploadAsync(fileStream, blobUploadOptions, ct) with no StorageTransferOptions, so the SDK's default 256 MiB InitialTransferSize applies and Retry.NetworkTimeout (set at line 28) bounds the whole transfer.

On the last point — agreed with both of you that the 256 MiB reasoning is size-dependent and stops applying above that threshold. At the current ~197 MB it holds, but it is not a size-independent rule and shouldn't be read as one later.

The two remaining doc nits (restoring a general "validate before advancing" clause, and the stale @v1.1 at line 207) are both fair — happy to fold them in if you'd like, though it would mean another force-push and another dismissed approval, so I'd rather batch them with any other review feedback than spend a round-trip on them alone. Your call.