[Bug] Solution export fails for any code app published on Dataverse 9.2.26091 — controlled repro (26084 works, 26091 fails); #454 has regressed

No repository file or test is identified; start with ExportSolutionAsync and asyncoperations().message, using the controlled 9.2.26084/9.2.26091 comparison and the publish-time distinction. Done means the platform regression is reproduced, tracked with the ActivityId and Azure Storage request ID, and an export path is restored or a documented resolution is provided.

Exporting any solution that contains a code app fails on Dataverse 9.2.26091.144 and succeeds on 9.2.26084.156 — same tenant, same day, same CLI, byte-identical app.

This is the regression from #454, which was closed on 8 Sep and reported as returned on 18 and 20 Sep. Opening a new issue because that one is closed and the last two comments there went unanswered.

The failure

Plugin/Microsoft.Crm.WebServices.ExportXmlService
  CanvasAppHandlerInternal.<ExportCodeAppBlobsForExportAndUpdateXmlNode>d__34
   -> StorageBlobDataProvider.<ListBlobNamesAndUrisInContainer>d__4
   -> Azure.RequestFailedException: 401 NoAuthenticationInformation
      Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
ErrorCode: -2147220970   (surfaces to callers as 0x80040216)

ExportSolution only returns 0x80040216. The stack above is only visible by calling ExportSolutionAsync and reading asyncoperations(<id>).message.

The controlled pair

This is what pins it to the platform build. The same minimal code app — a single static index.html, no scripts, no data sources — pushed with the same CLI (@microsoft/power-apps-cli 0.15.1) into two environments that differ only in build:

Environment	Dataverse build	Published	Export of its solution
A	9.2.26084.156	today 13:39 UTC	HTTP 200 — 2,632-byte zip containing CodeAppPackages/index.html
B	9.2.26091.144	today 13:41 UTC	0x80040216

What decides it is when the app was published, not when it is exported

In a single environment now on 26091:

• an app last published 5 days before that environment received 26091 exported fine that morning — a 313-file bundle, 2.6 MB zip, all 313 CodeAppPackages entries present;
• after one republish on 26091, the same solution stopped exporting.

So 26091 appears to break the creation of the code app's blob container at publish time. Containers written by earlier builds stay readable.

A practical consequence worth documenting: on an affected environment, an app that still exports is one push away from losing that ability.

Clean repro on an affected environment

New solution, a brand-new Dataverse table created inside it, and a one-file code app with that table as its only data source, published today. Export fails identically. Nothing pre-existing is involved — not app size, not a migrated solution, not legacy data sources.

Ruled out, each one tested

Hypothesis	Result
Publish client	@microsoft/power-apps-cli 0.15.1, pa 1.0.2 and pac 2.6.4 code push — all three produce an unreadable container
SDK / generated code	@microsoft/power-apps 1.4.0 + pa app refresh data-source across every table, rebuilt and repushed — still fails
Republishing (the 8 Sep workaround)	no longer helps; 4 republishes across 2 environments, no change
App size or contents	fails with one static file; succeeds with a 313-file bundle published pre-upgrade
Solution shape	fails for a brand-new solution containing one table and one app
TargetVersion on export	0x80040203 — "Exporting to a target version is not supported in this release"
CloneAsPatch, then export the patch	fails identically
Managed vs unmanaged	both fail
Caller identity	fails for an interactive user and for a service principal — not a permissions problem
Environment settings	enableipbasedstorageaccesssignaturerule = False, ipbasedstorageaccesssignaturemode = 0, no storage-SAS IP ranges, no IP firewall, external file storage off — identical in the working and the failing environments

The docs note that code apps access their storage through SAS and that the SAS IP-binding setting therefore does not apply to them, which is consistent with a SAS simply not being attached on this code path.

Impact

Every ALM route out of an affected environment is blocked, because they all go through export: pac solution export, the Web API ExportSolution / ExportSolutionAsync, Power Platform Pipelines, and Solution Checker.

There is no customer-side mitigation. The platform build is assigned per scale group; no environment lifecycle operation changes it (the allowed operations are Move, Backup, Copy, Delete, Edit, Recover, Reset, Restore, network-injection, identity, Enable/Disable, governance and tenant-to-tenant — none of them versioning), and updateCadence is already at its fastest setting. Restore and Reset restore data and customizations, not platform binaries.

Ask

Could this be reopened and tracked? Happy to provide the ActivityId and the Azure Storage x-ms-request-id from failing runs, plus exact timestamps, on request.