fix(codeintel): improve upload error hints for auth and permission failures#1259
fix(codeintel): improve upload error hints for auth and permission failures#1259chrapkowski-sg wants to merge 1 commit intomainfrom
Conversation
|
This change is part of the following stack: Change managed by git-spice. |
ac46f83 to
1ec19db
Compare
1ec19db to
d3d35f7
Compare
keegancsmith
left a comment
There was a problem hiding this comment.
LGTM
minor: please write a useful PR title before landing. Also when you do land this, your commit message doesn't need to include the large amount of test plan details.
| // findAuthError searches the error chain (including multi-errors from retries) | ||
| // for a 401 or 403 ErrUnexpectedStatusCode. Returns nil if none is found. |
There was a problem hiding this comment.
just checking my understanding: so the reason you can't just use errors.As is it will return the first found httpErr but you want to check all of them to find one which could be a 401/403.
There was a problem hiding this comment.
Correct. To give more context.
When retries happen, errors get combined into a MultiError. If e.g. the first attempt gets a (502 which did happen to me sometimes during testing) and a retry gets a 401, errors.As returns the first ErrUnexpectedStatusCode it finds (the 502), so the httpErr.Code == 401 || httpErr.Code == 403 check fails — even though an auth error exists in the chain.
Good points, thank you! |
| } | ||
| } | ||
| if err != nil { | ||
| return handleUploadError(cfg.AccessToken, err) |
There was a problem hiding this comment.
Removed here handleUploadError at this point only flags validation errors may occur and handleUploadError is about handling errors of during actual upload
| // findAuthError searches the error chain (including multi-errors from retries) | ||
| // for a 401 or 403 ErrUnexpectedStatusCode. Returns nil if none is found. |
There was a problem hiding this comment.
Correct. To give more context.
When retries happen, errors get combined into a MultiError. If e.g. the first attempt gets a (502 which did happen to me sometimes during testing) and a retry gets a 401, errors.As returns the first ErrUnexpectedStatusCode it finds (the 502), so the httpErr.Code == 401 || httpErr.Code == 403 check fails — even though an auth error exists in the chain.
When upload of a
scipindex fails, the error message may be misleading or incomplete. The complexity comes from two aspects. First that we have 2 tokens - sourcegraph access token and code host token. This PR makes sure that whenever a token is invalid we get most probable causes. Second part is that even if a token is valid on its own, the user may not have sufficient permission. https://github.com/sourcegraph/sourcegraph/pull/10077 makes the error codes and messages more consistent on the server side. This way user gets a hint if token was wrong or there was a permission problem.To summarise. First of all user gets error message from the server which often is specific (ex.
upload failed: must provide gitlab_token). However basing text returned by the server (server does not return structured response like JSON) is IMO fragile so except this error message user gets hints about possible problems.I believe those two together should eliminate confusion and point user in the right direction how to remediate the issue. We also always show the link to the documentation.
Additionally existing code was deducing used code host based on the repository URL hostname, here we also check the specified command line parameter. Those hints which are displayed to the user is not a new invention, those were just improved to provide user with more accurate information and to utilise information from the server which effectively is best source of truth what the problem was.
Test plan
Unit tests and additional integration tests were performed to make sure the provided hints work as expected