Handle more error codes when an RP isn't registered

[jhendrixMSFT]

There's more than one error code returned from unregistered RPs.

Fixes #20823

[jhendrixMSFT]

We could also add a string slice to RegistrationOptions to allow callers to add additional non-standard error codes to unblock themselves. Thoughts?

CC @JeffreyRichter

[JeffreyRichter]

I'm sure I'm missing context but when I look at #20823, it looks like the error code string was just wrong and that this bug should be fixed.

I can see the slight desire to look for error code strings (which should be compared case-sensitively, by the way - I mention this because I saw a call to EqualFold in #20823 but it looks that was may have been removed). But, since error codes are related to HTTP status code, the thing to check on would be BOTH status code AND error code string.
But, do we really have to add this additional infrastructure?

[jhendrixMSFT]

We do already check the HTTP status code and if it's a 409 then we look for this additional information.

Most services return MissingSubscriptionRegistration (I believe all services are supposed to use this error code when the RP is unregistered). However, the Quota service is returning MissingRegistrationForResourceProvider and I'm sure we can't change that at this point for compat reasons (I have an email out to Roopesh and you about this).

Adding a slice of additional error codes would let customers unblock themselves if/when a service returns a non-standard error code. That said, it's probably rare enough that the extra machinery isn't worth it (I don't feel strongly about it, just throwing the idea out there).

[JeffreyRichter]

Who owns the code that is doing this comparison?
If it's us (the SDK), then we can check for both strings.
If it's the customer, then they can check for the right (or both) strings.

[jhendrixMSFT]

It's the SDK.

[JeffreyRichter]

OK, so if you want to check for both strings, that's OK with me. Add a comment.

[chlowell]

Adding a slice of additional error codes would let customers unblock themselves if/when a service returns a non-standard error code. That said, it's probably rare enough that the extra machinery isn't worth it (I don't feel strongly about it, just throwing the idea out there).

👍 if there's one standard code, it's reasonable to assume the number of variants is small; this may be the only one. We can patch again if another variant turns up and add API if we come to believe there are many unknown variants.

[ms-henglu]

Hi @jhendrixMSFT ,

Thank you for fixing the issue, and I have another similar case: #19900, would you please also check it? Thanks!

The error is

 {
   "error": {
     "code": "Subscription Not Registered",
     "message": "Please register to Microsoft.Security in order to view your security status"
   }
 }

[jhendrixMSFT]

@ms-henglu could you please add this info and the URL that's returning this error code to the issue?

[ms-henglu]

@jhendrixMSFT - Sure, it's already in this issue: #19900

With track2 sdk, creating of a Microsoft.Security/pricings@2022-03-01 resource is failing to a newly created subscription without a registered Microsoft.Security provider.

│ PUT https://management.azure.com/subscriptions/[subscription-id]/providers/Microsoft.Security/pricings/VirtualMachines?api-version=2022-03-01
│ --------------------------------------------------------------------------------
│ RESPONSE 404: 404 Not Found
│ ERROR CODE: Subscription Not Registered
│ --------------------------------------------------------------------------------
│ {
│   "error": {
│     "code": "Subscription Not Registered",
│     "message": "Please register to Microsoft.Security in order to view your security status"
│   }
│ }
│ --------------------------------------------------------------------------------
│ 
│ 
╵

[jhendrixMSFT]

My mistake, I confused this with issue #20823