refactor(amazonqFeatureDev): include exceptions treated in code generation status detail

[tverney]

Problem

Currently we don't handle specific Guardrails type exception for code generation status detail, which leads to throw a general error and not help user self diagnose the prompt.

Solution

This PR proposes:

• Specific error handling for GuardrailsException, PromptRefusalException, EmptyPatchException, ThrottlingException
• Small refactor to use CodeGenerationStatus enum instead of single string

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[justinmk3]

what is the source of codeGenerationStatusDetail? is it an exception caught by mynah, or LSP, or some other component? If it's an exception, does it have a code that can be checked instead of string-matching the message?

[tverney]

Our BE its returning the exception in this format:

reason: ${error_type.slice(0, error_type.indexOf('Exception'))}

Which leads to a combination of exception plus the error code like this:

Mocked error message reason: Guardrails

So answering your question, don't have a code because the identifier comes with the message itself so requires string-match those.

[justinmk3]

Why doesn't the backend model the errors with a code? Surely this is possible with smithy/coral? Do you have plans to change this?

This is resulting in a lot of low-value boilerplate code in all of your clients (such as this repo).

[tverney]

Yes, we've had a brief discussion about this internally. BE team said that we couldn't afford an API shape model change at this point because would require an extra bar raising process. So, for now, as far I've understood from their response, it was decided to leverage the existing details field mapping the exception code within the message. Those strings are extracted from the exception code, the only difference is that its combined with the details string, which is a details message coming from the BE which wasn't being filled until now.

[jeffpyj]

Yes we have plans to improve the API shape for error propagation. In Q4 there is a planned UX/UI revamp work of our service and we plan to improve the backend models as part of that effort. This is more of a short term improvement to reduce some pain points that our customers have encountered.