feat: allow backend errors to be handled seperately #1167
Conversation
|
That was a demo message I threw in there to demonstrate, an actual error from the backend would display its message there. I can try to produce an ISE to show what this would look like. |
| // Show backend error messages to the customer. | ||
| if (err.code === 'QModelResponse') { | ||
| this.#features.logging.error(`QModelResponse Error: ${JSON.stringify(err)}`) | ||
| return new ResponseError<ChatResult>(LSPErrorCodes.RequestFailed, err.message, { |
There was a problem hiding this comment.
can we add a special check here to show this message when statusCode is 500?
https://github.com/aws/aws-toolkit-vscode/pull/6984/files
There was a problem hiding this comment.
Is it safe to assume 500 is throttling? Isn't this also ISE?
Edit: I was able to get a 500 below unreleted to throttling when I passed {} as the args.
There was a problem hiding this comment.
you are right, right now this is a gap in our system where we couldn't differentiate bedrock throttling and real ISE. Given the fact that we just got a lot of capacity and we fallback to 3.5, the chance of real throttling happening is low so maybe it's fine to keep this as it is for now
|
@velatha Internal failure error demo: ISE-Error.mov |
Problem
Backend error messages are expected to be shown directly to the customer in chat. However, there are other error messages we don't want to show, and should show a generic message.
Solution
codefield, that allows each type of error to have its own handling.tryblock such that any internal errors surfaced are caught and returned asResponseError. This also makes this easier to test.Testing and Verification
backendErrorDemo.mov
unknownError.mov
License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.