refactor: propagate model errors via LSP response errors.

[Hweinstock]

Problem

• Some follow up work from fix: implement proper error handling. #1115.

Solution

• Follow the LSP paradigm to return response error to the client, and handle it there.
• This is in combination with client side changes here.
• These together produce the following experience on model api failures.

License

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

[jpinkney-aws]

will the error cause message be logged and then the other body be shown to the user?

[Hweinstock]

Yeah, see the screenshot I added above. I was debating trying to parse the requestId and include it in the chat message (done on the agentic-chat vsc branch), but I think it makes more sense to be the logs since its a technical detail and only useful for internal users.

I think ideally we add a button to this chat message that opens the logs (like we do in most VSC error messages). However, this is not a p0 to me since it requires a decent amount of work to allow Flare to open IDE logs.

[jpinkney-aws]

Makes sense that we should be handling it this way, we just had to make a quick judgement call for the bug bash yesterday 😅

[volodkevych]

Thanks for the followup 👍

[Hweinstock]

Should be safe to assume this is merged with client side changes with the version fixing setup, but want to double-check in case they get out of sync since this is fairly critical. Will take out of draft once I've verified.

[Hweinstock]

Verified these PRs can go in either order. Ideally client side first, but it doesn't break anything.

I did notice a bug where thinking doesn't go away sometimes on the happy path, but this is also on main and is not related to this change. Here is the demo on main here, and hybrid chat latest VSC:

thinkingBug.mov