Update-InAppProductSubmission w/-Force has Conflict

[adamhewitt627]

Environment:

• ModuleVersion 1.17.0
• PSVersion 5.1.17134.165
• Windows 10 - 1803

This may be more of a failure with the Store backend than StoreBroker, but using this command:

Update-InAppProductSubmission $IapId $dataPath -UpdateListings -UpdatePricingAndAvailability -Force -AutoCommit

Sometimes, the backend returns 503, but actually creates a submission. Since the -Force check has already been done, the subsequent retry produces an error:

DONE (FAILED) - Operation took 8 second(s) [Cloning current submission for IAP: ...]
WARNING: 2018-07-26 11:25:03 : AdamHewitt : 503 | Service Unavailable
The remote server returned an error: (503) Server Unavailable.
InvalidOperation : This operation cannot be completed at this time. Retry your operation using exponential backoff.
MS-CorrelationId: c01d1257-1685-4217-b46d-dc11c11ccb9d
WARNING: 2018-07-26 11:25:03 : AdamHewitt : This status code (503) is configured to auto-retry (via
$global:SBAutoRetryErrorCodes).  StoreBroker will auto-retry (attempt #1) in 1 minute(s). Sleeping...
DONE (FAILED) - Operation took 5 second(s) [Cloning current submission for IAP: ...]
Write-Log : 2018-07-26 11:26:09 : AdamHewitt : 409 | Conflict
The remote server returned an error: (409) Conflict.
InvalidState : In app product already has an in-progress submission

Expected: the retry should succeed unless the service is still unavailable. Either by checking again for a pending submission (and deleting it) or use the created submission and continue.

[HowardWolosky]

Thanks for the report, Adam.
When we implemented auto-retry support in StoreBroker with commit d13cc9dcc, we did it at the "atomic" level (meaning, at an individual REST API request). We've heard feedback from users that for the New-FooSubmission commands, that doesn't really work well with the current types of problems that the API is having.

The API team has heard this feedback and is preparing a workaround for retail submissions that StoreBroker v1 will be implementing within the next couple days, but it doesn't address this problem when it manifests while trying to create new Flight or IAP submissions.

At this point, core development effort is being focused on v2 of StoreBroker which works against a new version of the API that is coming out in the future (you can see that ongoing work here). I'm keeping this type of issue in mind for v2 and planning on having functional-level retry support as an optional alternative to atomic-level (depending on the scenario). Depending on the complexity of that implementation, I may attempt to backport it to v1, but that all depends on available time.

In the short-term, if you're experiencing this type of failure with the Store pretty regularly, your best bet would be to disable auto-retry (by specifying no retry error codes), and then wrap your Update-InAppProductSubmission call in a try/catch with its own retry.

Sorry for the hassle. Please keep the feedback coming though.

[adamhewitt627]

Thank you for the detailed response, I will look forward to v2, and see about handling the try/catch myself. It hasn't been too bad yet, but I've also only been trying with a small portion of our catalog. Will need more complete error handling when we unleash the additional thousands of products.