Template Message for limit reached with scenario deliverable

[naman-msft]

Ran into this while creating the static web app exec doc. If I ran the process using IE a few times, it would cause an error when I tried creating the static web app again: you have reached the limit of static web apps you can create. please delete

So, for other deliverables in exec docs (that I assume can be run multiple times), if such an error comes up, it should be handled by a template message along the lines of Sorry! You have reached the maximum number of {product_name} that can be created under your usage tier. Kindly delete them to rerun this exec doc.

[vmarcella]

This is a bit tough to implement because that error comes from the azure-cli command to create the web app. We'd need to add specialized functionality to check the errors from azure-cli commands which may have quotas to determine if a particular error did occur because of a quota.

[mbifeld]

@naman-msft is your suggestion to check ahead of the doc being ran if this error would arise or just to show a slightly more detailed error output when the error actually occurs during execution?

[naman-msft]

@mbifeld @vmarcella in terms of feasibility, I would say having a more scoped out template message for these kinds of errors makes sense - but this is for the portal experience. You could always add this detail in IE and handle it accordingly i.e. whenever this message is triggered, do some troubleshooting on IE - either give a link to deleting it, or some other way.

For the short-term, is there a way to handle these azure cli command errors by showing this message on portal?

[vmarcella]

@naman-msft I'm closing this out because I think that the troubleshooting text should be on the azure-cli, and more specifically the azure-cli modules like the one used for creating a web apps. IE is a proxy for running commands and should do as little as possible to actually change the outputs/errors returned from those commands. If there's a problem with the usefulness of the messaging, we should address it at the source to improve the experience end-to-end.

There's also no guarantee that this error message doesn't get changed by the azure-cli in the future, which could break our templating in the portal experience, and modifying the outputs from these commands will only add more confusion to users if they decide to run the commands themselves and don't get the same feedback that they did when running it within IE.