´msstore publish´ hangs on Submission Status - CommitStarted

[meakbiyik]

Both on my workstation and CI, the msstore publish -i ".\release\build" command hangs on "Submission Status - CommitStarted". When I look at the partner center, I see that although the previous (manual) submission works without issues, the new submission by CLI appears buggy, see "Pricing and Availability" warning below. Waiting over 1 hour does not change the status. If it helps, there are no other errors, and it is an electron app.

[meakbiyik]

There does not seem to be anything out of ordinary in the logs when I run the command with ´-v´, only the following warnings repeat:

[azchohfi]

This is the normal execution of the publishing process. It will stay at Status=CommitStarted until it passes the first steps of certification, which might take a while. The CLI pools every 30 seconds, until it changes to something else, then it report it.

[meakbiyik]

Oh that I am aware, but should I expect it to take over 1 hour?

The behavior was consistent in my local and the Github Action, which is sadly not acceptable if we want to automate the publishing process.

To follow my steps: I have an electron app, I package it with npm exec electron-builder -- --win which builds the appx bundle, then I run msstore publish -i ".\release\build", and the code polls for one hour with the following output repeated and times out at the end.

[meakbiyik]

This is the normal execution of the publishing process. It will stay at Status=CommitStarted until it passes the first steps of certification, which might take a while. The CLI pools every 30 seconds, until it changes to something else, then it report it.

I also found one point in your comment interesting: does the CommitStarted status wait until the first steps of the certification process is concluded? Because the issue I report appear to happen before the certification starts, since the submission does not appear in a submitted for certification state on the user interface, see that the submit to the store button in the first figure I added still appears (yet disabled). Below is the UI for a properly submitted package:

My guess is that CLI configures the package metadata (most probably some field in the pricing and availability section) erroneously and therefore the package cannot be submitted to certification, and the app gets stuck in the commit started phase.

[meakbiyik]

I have a new symptom: without any changes to the pipeline or the cli, I started to get the following error (IDs are removed)

✅ Zip Bundle is configured and ready to be uploaded!
Uploading Bundle to Azure blob: 8%
Uploading Bundle to Azure blob: 72%
Uploading Bundle to Azure blob: 93%
✅ Successfully uploaded the application package.
Waiting for the submission commit processing to complete. This may take a couple
of minutes.
Submission Committed - Status=CommitStarted
Submission Status - CommitStarted

Submission Status - CommitStarted

Submission Status - CommitStarted

Submission Status - CommitStarted

Submission Status - CommitStarted

Submission Status - CommitFailed
                              ❗ Submission Errors                              
┌───────────────────────┬──────────────────────────────────────────────────────┐
│ Code                  │ Details                                              │
├───────────────────────┼──────────────────────────────────────────────────────┤
│ InvalidParameterValue │ Error. Request it is not IngestionWeb or             │
│                       │ IngestionApi. applicationId = xxx,            
│                       │ submissionId = xxx, The                  
│                       │ ClientIdentifier = IngestionAPIv1Worker              │
└───────────────────────┴──────────────────────────────────────────────────────┘

Submission has failed. Please check the Errors collection of the 
submissionResource response.

[azchohfi]

Are you still facing this issue?

[meakbiyik]

Yup, so I needed to disable auto-publish in the pipeline. Did you push a fix for it? I can test in the next release.

[azchohfi]

This seems to have been an intermittent issue with the service. I would try again, since we published a number of new versions or the cli.

[bitbound]

I have the same issue. It never progresses passed "Commit Started". I have to go into the Partner Center and manually submit it.

After that, the command (and my DevOps pipeline) completes successfully.

I'm not sure if this is significant, but when I went to the Partner Center to check the submission, my new package was in the submission, but it still said "Unchanged" next to packages. I went in there to double-check that it was the correct version, clicked Save, and then it showed as "Updated"

[brandonp2412]

Yep mines stuck in a loop waiting for "Submit for certification" to be clicked in the Microsoft Partners website. After I did that manually the tool said it was successful and stopped.

Example failure can be seen https://github.com/brandonp2412/FitBook/actions/runs/10016988534/job/27690626996 where i cancelled it after about 30 minutes of hanging.

[itm-github]

Are there any updates for this issue? Are anyone found a solution? I got the same problem an about two months. I create the app in the portal and published it. Next I was try to automate the building and publishing app with pipeline but the same issue as in this thread. When I publish the Submission - it stuck on CommitStarted status and after a day or two finished with CommitFailed status. It is interesting that if I just create a new submission (with Powershell StoreBroker module) next publish the Submission without any change - the Submission successfully goes into PreProcessing and next states. If I change even one field in the Submission (targetPublishMode, for example) - the Submission stuck on CommitStarted state. This same behaviour I got when using Powershell StoreBroker module and direct requests to the API with Python.

[bitbound]

Are there any updates for this issue? Are anyone found a solution? I got the same problem an about two months. I create the app in the portal and published it. Next I was try to automate the building and publishing app with pipeline but the same issue as in this thread. When I publish the Submission - it stuck on CommitStarted status and after a day or two finished with CommitFailed status. It is interesting that if I just create a new submission (with Powershell StoreBroker module) next publish the Submission without any change - the Submission successfully goes into PreProcessing and next states. If I change even one field in the Submission (targetPublishMode, for example) - the Submission stuck on CommitStarted state. This same behaviour I got when using Powershell StoreBroker module and direct requests to the API with Python.

I haven't found a solution yet. I've been going into Partner Center and manually submitting every time.

[CL-vc]

After experiencing this issue for a while, it seems to have been resolved somehow. While the exact cause is unclear, the process of uploading a .msix file to the Microsoft Store through the CLI now successfully finishes, and submits the submission for certification, at least for me.

[maxded]

I've recently started experiencing the same issue. For the past six months, my CI pipeline has consistently packaged my project as an MSIX and submitted it to the Microsoft Store using the msstore publish command. However, a few weeks ago, this process broke: the command now gets stuck at Submission Status - CommitStarted, as others have reported. This means that a draft submission is created but no longer proceeds automatically to certification as it did before. Previously, msstore publish would complete in about 10 minutes. Now, it runs for hours without progressing past the CommitStarted status—strongly suggesting something is wrong.

Another concerning issue is that when the submission gets stuck at CommitStarted, the resulting draft submission unexpectedly resets the base price to Free. This is especially dangerous because the draft's overview misleadingly claims that the "Pricing and availability" settings are unchanged, even though they clearly are not.

I'm not sure if these issues are directly related or if they're problems with the msstore CLI tool itself, but I wanted to mention them here since they seem similar to what others have reported.