Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Overloaded" message from API - UX suggestion #857

Open
i13-ctflora opened this issue Nov 26, 2024 · 4 comments
Open

"Overloaded" message from API - UX suggestion #857

i13-ctflora opened this issue Nov 26, 2024 · 4 comments
Labels
feature request ux UX improvement

Comments

@i13-ctflora
Copy link

Is your feature request related to a problem? Please describe.
When the API returns an "Overloaded" method, there's a brief Obsidian notification, but no other visual indicator in the Copilot window. If you miss the notification, there's no way to tell what's happening except via the web console, which most users wouldn't think to check (or know how to check).

Describe the solution you'd like
Since the Obsidian notifications disappear so quickly, it would be great to have some sort of visual notification of the problem in the Copilot window. Maybe a red X by your prompt, or red shading of the prompt area, with the note in red text under the prompt beside the timestamp. Also, a more descriptive error would be useful - I had to pull up the console and google the error message to understand what was happening. Especially for the Overloaded error, it would be great to explicitly state that the user should try again shortly, and maybe even include a 'retry' button that copies the errored prompt into the prompt input box and resends it.

Describe alternatives you've considered
Maybe 500 errors from the model API can clearly state that the errors are from the API, not from Copilot? Maybe 500 errors could use yellow shading or "warning" symbols (with the 'try again' button), while 400 errors could use red "error" symbols (with links to the model's API page)?

Additional context
This isn't super important, but would be a great UX addition for users.

@i13-ctflora i13-ctflora changed the title "Overloaded" message from API - UX suggestions "Overloaded" message from API - UX suggestion Nov 26, 2024
@logancyang
Copy link
Owner

Is it better to have every popup error notice as an AI message in the chat, it's clearer and not going to disappear.

Anything other than error messages? What do you mean by "overloaded method"?

@logancyang logancyang added the ux UX improvement label Nov 26, 2024
@i13-ctflora
Copy link
Author

My preference would be to have any 4xx or 5xx messages from the API show in the chat, yes. The 'overloaded' message I'm referring to may be specific from Anthropic Claude, it's their 529 error. The OpenAI equivalent is the 503 error. These are the errors that the API sends back when it's too busy and wants you to try again later. From what I can see on those two pages, the 5xx errors in general could benefit from a 'retry' button, while the 4xx errors would not.

@logancyang
Copy link
Owner

@i13-ctflora ah gotcha. So (better) error message in chat is definitely needed.

Just an FYI, Copilot does 3 auto retries in the background, there's also a regenerate button.

@i13-ctflora
Copy link
Author

The regenerate button only exists on the AI response, and when this error occurs there's currently no AI response, just the prompt window with the copy & edit buttons
And while yes, you can use those buttons or press the up-arrow button in the prompt window and then press Enter. But the alternate approach (and good UX practice) would be to have a simple way to retry the prompt in the case of a 5xx error since that's generally the only thing you'd want to do. Maybe not even a button, but simply make the error message a clickable retry event (so you don't clutter the existing layout further).

In terms of prioritizing, though, I'd say that displaying the errors is "need-to-have" while the retry functionality is "nice-to-have".

And thanks for the info about the retries, I did not know that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request ux UX improvement
Projects
Status: Ready
Development

No branches or pull requests

2 participants