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

Handle network disconnection #107

Merged
merged 10 commits into from
Jul 27, 2023
Merged

Handle network disconnection #107

merged 10 commits into from
Jul 27, 2023

Conversation

deepak2431
Copy link
Contributor

@deepak2431 deepak2431 commented Jul 12, 2023

This PR closes #43. It handles the network error for the DOTCOM instance. It handles the server disconnection due to network issues by adding an appropriate message. Also, add a reload button to return when the user is back in the network.

Test plan

All tests have passed.

REC-20230725162020.mp4

@deepak2431 deepak2431 marked this pull request as draft July 12, 2023 07:23
@deepak2431 deepak2431 marked this pull request as ready for review July 12, 2023 18:11
@deepak2431
Copy link
Contributor Author

@abeatrix Can I have a review, please?

Copy link
Contributor

@abeatrix abeatrix left a comment

Choose a reason for hiding this comment

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

i left some comments inline with some minor change request, the rest looks good to me!
Will defer to tim on the design :D

case 'settings':
await this.authProvider.auth(message.serverEndpoint, message.accessToken, this.config.customHeaders)
case 'settings': {
const endpoint = message.serverEndpoint.length ? message.serverEndpoint : this.config.serverEndpoint
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you tell me more about this change?
This is called when a user input the endpoint and access token manually, so it doesn't make sense to me to replace them with the ones from this.config if those are not available 👀

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay so when reload button is clicked, we need to get the token and endpoint to initiate the Re-LOGIN for the user. So, this change handles both reload cases and when sign-in is done manually. But I think it would be BEST to do it in a separate message protocol. LMK, what do you think?

@@ -386,8 +389,18 @@ export class ChatViewProvider implements vscode.WebviewViewProvider, vscode.Disp
if (isAbortError(err)) {
return
}
// check first if search error is due to any network issue
if (isNetworkError(err)) {
void this.sendErrorToWebview(
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 instead of this.sendErrorToWebview(), we should use this.transcript.addErrorAsAssistantResponse() (or both) to avoid having missing bot response item:
image

i think the only time we can have a boy response item is when the message is aborted manually, what do you think? 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It would be good to have both of them, as ENOTFOUND error as error assistant response shows up. So, this won't be much clear for the user as to why this is happening, so it would be better to include both. LMK, if you agree to this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea let's see what tim thinks but what what you suggested makes sense to me :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, will wait for him to confirm.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@toolmantim What about this?

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 outputting it into the chat as a bot response is enough, we don't need an additional error at the top also. We could restyle the error bot responses to be red or make it clearer, but that can happen in a follow-up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That sounds good to me. To mention, for now, there's an implementation of ErrAssistantResponse to show in the chat so after removing this webview error that would be displayed in case of an error.

return (
<>
<div className={styles.error}>
<p>{AUTH_ERRORS.NETWORK_ERROR}</p>
Copy link
Contributor

Choose a reason for hiding this comment

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

I like this! Maybe we can show the endpoint address to let the user know which instance is having network issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That would be a good add on, I will update it.

<>
<div className={styles.error}>
<p>{AUTH_ERRORS.NETWORK_ERROR}</p>
<VSCodeButton className={styles.button} type="button" onClick={handleReload}>
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe update the button styles to have full width like the rest of the buttons in the login page? Will defer to @toolmantim who will be back next week from his PTO :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, we can have that so it would be align to the style with all other buttons.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd love us to move away from the-full width buttons… but it's good to be consistent. But given it's an error state, I'm okay with just leaving this as a normal button w/ inherent width.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it, thanks @toolmantim

@deepak2431
Copy link
Contributor Author

@abeatrix Thanks for the review! Can network errors be handled when the Sign In is done using Cody App? I tried this but couldn't get a working solution.
Also, do you mind testing it once for the enterprise test customer instance to ensure it works perfectly for that cases too?

@deepak2431
Copy link
Contributor Author

@toolmantim Can you please look at this and add your comments about the flow and the button CSS so I can make those changes?

@deepak2431 deepak2431 closed this Jul 23, 2023
@deepak2431 deepak2431 reopened this Jul 23, 2023
@deepak2431 deepak2431 requested a review from abeatrix July 24, 2023 13:22
@abeatrix abeatrix requested a review from umpox July 24, 2023 17:20
@abeatrix
Copy link
Contributor

Left an in-line comment. Also adding @umpox as reviewer as he's working on refactoring the chat view that could be related 😃

@deepak2431
Copy link
Contributor Author

@abeatrix I think you forgot to submit the inline comments as I can't see them. Looking forward to review from @umpox

Copy link
Contributor

@abeatrix abeatrix left a comment

Choose a reason for hiding this comment

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

See inline comment.
Will defer to @umpox for final approval as this made changes in the refactoring work he is working on.

await this.authProvider.auth(message.serverEndpoint, message.accessToken, this.config.customHeaders)
case 'settings': {
const endpoint = message.serverEndpoint.length ? message.serverEndpoint : this.config.serverEndpoint
const token = message.accessToken.length ? message.accessToken : this.config.accessToken
Copy link
Contributor

Choose a reason for hiding this comment

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

What if the user manually input a new endpoint but didn't provide an access toke? That means we will try to log the user in with the access token from this.config that is meant to use with the endpoint in this.config?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, agree that would be the case here based on the implementation logic. It would be better to separate this in different messages as reload, in which we check the config values and login the user. WDYT, LMK?

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 separating this into reload is a good idea 👍

Copy link
Contributor

@umpox umpox left a comment

Choose a reason for hiding this comment

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

Left a couple of comments!

Comment on lines 17 to 18
NETWORK_ERROR:
'Due to network-related problems, Cody cannot be reached. Try again after checking it! Once your connection is restored, attempt a reload.',
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
NETWORK_ERROR:
'Due to network-related problems, Cody cannot be reached. Try again after checking it! Once your connection is restored, attempt a reload.',
NETWORK_ERROR:
'Connection failed due to a network problem. Please check your internet connection and try again.',

Small copy change to make this a bit simpler

await this.authProvider.auth(message.serverEndpoint, message.accessToken, this.config.customHeaders)
case 'settings': {
const endpoint = message.serverEndpoint.length ? message.serverEndpoint : this.config.serverEndpoint
const token = message.accessToken.length ? message.accessToken : this.config.accessToken
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 separating this into reload is a good idea 👍

@deepak2431
Copy link
Contributor Author

@umpox @abeatrix Made all the requested changes. Also, I updated the error message in the assistant response in case of network error to be clear about that. Check the updated video in the PR description for the final behaviour.

@abeatrix
Copy link
Contributor

@deepak2431

@umpox @abeatrix Made all the requested changes. Also, I updated the error message in the assistant response in case of network error to be clear about that. Check the updated video in the PR description for the final behaviour.

can you resolve the merge conflicts before we check out the branch please? Thanks!

@deepak2431
Copy link
Contributor Author

@abeatrix Resolved the conflicts and updated the code as per the refactor of ChatView.

Copy link
Contributor

@abeatrix abeatrix left a comment

Choose a reason for hiding this comment

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

worked as expected! Thanks @deepak2431 !!

Copy link
Contributor

@umpox umpox left a comment

Choose a reason for hiding this comment

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

🚀

@abeatrix abeatrix merged commit 0714046 into sourcegraph:main Jul 27, 2023
6 checks passed
@deepak2431 deepak2431 deleted the deepak/network_disconnect branch November 14, 2023 06:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cody: Handle network error disconnection
5 participants