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

plg: display errors when autocomplete rate limits trigger #2135

Merged
merged 5 commits into from
Dec 8, 2023

Conversation

kalanchan
Copy link
Contributor

@kalanchan kalanchan commented Dec 6, 2023

Closes #2134

This bug has 2 parts to it:

  1. Using the rate limited demo accounts, by design the headers retry-after return back the same time as when the request was made. This causes the error messages to constantly be displayed in the quick pick view
  2. Also using the rate limited demo account, if you hard code the retry time to a later time (like 1 day after), the error message does not display anymore after being dismissed once.

This PR adds a check to see whether or not the errors have been added in the statusBar and to display the rate limited error if no other RateLimitError is present. This also makes sure the error is only displayed once, instead of spamming the user if autocomplete keeps getting triggered.

Before (bug 1):

CleanShot.2023-12-05.at.17.41.29.mp4

Before (bug2, after hardcoding a later retry-after date):

CleanShot.2023-12-05.at.17.35.22.mp4

After:

CleanShot.2023-12-05.at.17.38.25.mp4

Test plan

  • login to https://sourcegraph.com using the free demo account (thread)
  • go to any file, trigger autocompletes multiple times and you will see only 1 error message displayed
  • click on the error, dismiss it, and trigger another autocomplete. you should see another error message displayed

Copy link
Contributor

@DanTup DanTup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me - added some nits (feel free to ignore!).

@@ -575,7 +575,16 @@ export class InlineCompletionItemProvider implements vscode.InlineCompletionItem
*/
private onError(error: Error): void {
if (error instanceof RateLimitError) {
if (this.resetRateLimitErrorsAfter && this.resetRateLimitErrorsAfter > Date.now()) {
let hasRateLimitError
const allStatusBarErrors = this.config.statusBar.checkErrors()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be simplified to something like:

const hasRateLimitError = this.config.statusBar.checkErrors().find(statusError => statusError.error.errorType === error.name)

(although maybe it's worth wrapping up as adding this.config.statusBar.hasError(error.name)?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thats why you're my TL! thanks danny I made your suggestion

Comment on lines 21 to 24
checkErrors(): {
error: StatusBarError
createdAt: number
}[]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to use a method checkErrors() rather than just using errors (exposing the underlying field)? I ask because the name feels a little odd to me - it's getting the errors, not really checking anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good call! changed this to hasError in the latest commit

Copy link
Contributor

@philipp-spiess philipp-spiess left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by design the headers retry-after return back the same time as when the request was made.

Wait this doesn't really make sense, shouldn't it be a time in the future at which we can retry the requests again? If we set it to the same time, what value does the header bring?

I’m pretty sure it worked like this before 😅

Comment on lines 21 to 24
checkErrors(): {
error: StatusBarError
createdAt: number
}[]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be done by setting a bit in the inline-completion-item-provider and then using the callbacks to reset it and avoid exposing this interface?

@philipp-spiess
Copy link
Contributor

I think something with the rate limited test account might be incorrect as it says "limit will reset in less than a minute". This isn't how our rate limiter works AFAIK?

@philipp-spiess
Copy link
Contributor

Screenshot 2023-12-06 at 11 44 25

There is clearly something I misunderstand about this header 😆 Should we remove the text that depends on the retry-after value?

@philipp-spiess
Copy link
Contributor

Copy link
Contributor

@philipp-spiess philipp-spiess left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gogog

@@ -9,6 +10,7 @@ import { FeedbackOptionItems } from './FeedbackOptions'
interface StatusBarError {
title: string
description: string
errorType: string | RateLimitError
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
errorType: string | RateLimitError
errorType: string

That should not be set to a class I assume? 🤔

Copy link
Contributor

@DanTup DanTup Dec 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this to type StatusBarErrorName = 'auth' | 'RateLimitError' for now (these are the only two we use), since it felt a little less error-prone than just string.

Also pushed some fixes to the tests because the mocks didn't have the hasError impl.

@DanTup
Copy link
Contributor

DanTup commented Dec 8, 2023

@kalanchan pushed some tweaks (363a716), think this is good to merge?

@kalanchan
Copy link
Contributor Author

@philipp-spiess @DanTup THANKS ALL for reviewing and helping, feels good to be contributing back to the team 💪

@kalanchan kalanchan merged commit 9b32d52 into main Dec 8, 2023
14 checks passed
@kalanchan kalanchan deleted the kalan/fix-autocomplete-error-display branch December 8, 2023 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

bug: Autocomplete rate limits display inconsistent error messages
3 participants