Submission stuck on CommitStarted status

[MrCapitalQ]

I'm having a weird issue where after creating a submission with the StoreBroker and Complete-ApplicationSubmission on it, the submission moves into the CommitStarted status but then never moves to any other status or produce any errors even after waiting over a day.

If I go into the Partner Center portal, I will see that submission sitting there with the option to "Submit to the Microsoft Store" (to my understanding, this is expected since the status in the portal doesn't update until it goes into certification). From here, I can just click on "Submit to the Microsoft Store" link without any modifications to the submission and it will go into pre-processing and certification without issue within a few minutes and eventually the certification passes. Seems like it's only getting stuck when it's being committed via the StoreBroker.

This is occurring on two apps that were created more recently but this doesn't happen on an older app using this same process. The StoreBroker is able to create a submission and commit it without intervention in the Partner Center portal. I also tried comparing the submissions for difference in case there were validation errors that weren't showing up but even after trying to make the submissions of the working one and the non-working ones as close as possible, this still occurs. The exception to this is pricing.isAdvancedPricingModel is false using the StoreBroker that I can't seem to change that becomes true after committing from the portal. Also there is a allowTargetFutureDeviceFamilies called "7" that disappears when committing from the portal but I can't remove it with the StoreBroker. Not sure if either of these are related.

Not sure where else to look from here or if there's something I'm missing. I'm thinking there's something to do with these specific apps since another one of my apps works fine with a nearly identical app package and listing properties but I'm not sure what it could be.

[HowardWolosky]

It's been over five years since I've dealt with the v1 API, so my memory may be hazy here, so take what I say with a grain of salt. If you commit from the portal, that commit won't include any of the changes that you made with the API...it'll simply be a direct copy of the submission it was cloned from. That could explain why you're seeing it seemingly revert some changes (like advanced pricing model) when submitting through the portal.

@MrCapitalQ - Are you using Start-SubmissionMonitor to monitor the changes to the submission status? Is that how you're noticing that nothing changes after a day?

If you're able to consistently repro this, please provide the CorellationId from the response to Complete-SubmissionId, as well as from some of the Get-ApplicationSubmission calls that Start-SubmissionMonitor uses behind the scenes. You'll find these in your StoreBroker.log as well as on the screen (if you're using -Verbose). I can pass that info along to the Store API team to see if there's something going on behind the scenes with the API that they need to investigate.

[MrCapitalQ]

Interestingly, when I commit from the portal, it kept the changes I made via the StoreBroker but that was just mainly replacing the package with a newer version so that may be treated differently from the other properties.

And I'm not using Start-SubmissionMonitor but instead checking the submission state using Get-ApplicationSubmission. I originally called that every minute as part of my script for 15 minute but since this issue has been occurring, I've also been manually calling this to check the status every few hours to see if anything has changed. One time, I just committed and then check a day later (24+ hours).

I also able to consistently repro this with 2 of my apps. I re-ran the StoreBroker calls and here is the correlation ID for the first one committing the submission and a call to check for the status some time later.

2024-05-02 19:38:15 : VERBOSE : MS-CorrelationId : faca210a-b236-494b-b8bd-8139f2ff17d4
2024-05-02 19:38:15 : VERBOSE : [1.21.2] Executing: Set-TelemetryEvent -EventName "Complete-ApplicationSubmission"
...
2024-05-02 19:53:24 : VERBOSE : MS-CorrelationId : 5607069b-f0a8-4b7b-8674-c6fa49d0840c
2024-05-02 19:53:24 : VERBOSE : [1.21.2] Executing: Set-TelemetryEvent -EventName "Get-ApplicationSubmission"

And here's some for the second app I have the same issue with.

VERBOSE: 2024-05-03 00:20:24 : MS-CorrelationId : 1b92a3f1-de60-4cff-a15f-e42ac6801e57
VERBOSE: 2024-05-03 00:20:24 : [1.21.2] Executing: Set-TelemetryEvent -EventName "Complete-ApplicationSubmission"
...
VERBOSE: 2024-05-03 00:35:28 : MS-CorrelationId : 42c07bef-ea9e-49de-bde0-eae516eda759
VERBOSE: 2024-05-03 00:35:28 : [1.21.2] Executing: Set-TelemetryEvent -EventName "Get-ApplicationSubmission"

I really appreciate you taking the time to respond and passing this along to the Store API team. Let me know if there's a better channel for this kind of problem in the future.

[camnewnham]

Our CI has started encountering this too. We haven't made any changes to this part of the pipeline for a while, but for the last few CI builds (which suits the date of this commit) I have noticed that everything appears to be working as normal but the submission doesn't actually get submitted or enter validation/certification. We don't monitor the submission via CI (instead relying on emails from the store for status).

Clicking "Submit to Microsoft Store" in the GUI works as expected - but previously wasn't required.

The commands we use are:

Set-StoreBrokerAuthentication -TenantId ${{ secrets.AZURE_TENANT_ID }} -Credential $cred
New-StoreBrokerConfigFile -Path "./SBConfig.json" -AppId ${{ secrets.AZURE_STORE_ID }}
New-SubmissionPackage -ConfigPath SBConfig.json -AppxPath "${{ steps.find_file.outputs.UPLOAD_FILE_PATH }}" -OutPath .\Upload -OutName upload
Update-ApplicationFlightSubmission -AppId ${{ secrets.AZURE_STORE_ID }} -FlightId ${{ secrets.AZURE_FLIGHT_ID }} -SubmissionDataPath  ".\upload\upload.json" -PackagePath ".\upload\upload.zip" -AutoCommit -Force -ReplacePackages

From the tail end of the actions run:

|  Elapsed: 4 second(s) [Committing submission *** for App: *** Flight: ***]
/  Elapsed: 4 second(s) [Committing submission *** for App: *** Flight: ***]
DONE - Operation took 4 second(s) [Committing submission *** for App: *** Flight: ***]
2024-05-30 07:27:26 : runneradmin : The submission has been successfully committed.
This is just the beginning though.
It still has multiple phases of validation to get through, and there's no telling how long that might take.
You can view the progress of the submission validation on the Dev Portal here:
    https://partner.microsoft.com/en-us/dashboard/products/***/submissions/***/
or by running this command:
    Get-ApplicationFlightSubmission -AppId *** -Flight *** -SubmissionId *** | Format-ApplicationFlightSubmission
You can automatically monitor this submission with this command:
    Start-ApplicationFlightSubmissionMonitor -AppId *** -Flight *** -SubmissionId *** -EmailNotifyTo runneradmin

PLEASE NOTE: Due to the nature of how the Store API works, you won't see any of your changes in the
Dev Portal .............
***

[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 commit 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 a New-ApplicationSubmission command and next commit 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 msstore CLI and direct requests to the API with Python.

[HowardWolosky]

I've sent a message to the Store API team regarding this thread. Will report back if/when I hear anything.