fix(amazonq): increase frequency of bearer token sync to server #5636
Conversation
| tokenSyncTask = scheduler.scheduleWithFixedDelay( | ||
| { | ||
| try { | ||
| if (isQConnected(project) && !isQExpired(project)) { |
There was a problem hiding this comment.
isQExpired
fun isQExpired(project: Project): Boolean {
val manager = ToolkitConnectionManager.getInstance(project)
val qState = manager.connectionStateForFeature(QConnection.getInstance())
val cwState = manager.connectionStateForFeature(CodeWhispererConnection.getInstance())
LOG.debug {
"qConnectionState: $qState; cwConnectionState: $cwState"
}
return qState == BearerTokenAuthState.NEEDS_REFRESH || cwState == BearerTokenAuthState.NEEDS_REFRESH
}
make sure JB itself can automatically switch from NEEDS_REFRESH status to other status.. otherwise if JB stuck in NEEDS_REFRESH, this won't sync
There was a problem hiding this comment.
Otherwise, this PR looks good
There was a problem hiding this comment.
What do you mean by this? Isn't refresh logic handled by calls to reauthConnectionIfNeeded everywhere? If the IDE idles out and the token is no longer syncing because it needs to be refreshed, isn't that expected? We could add something to try and refresh the token here when it's expired, but I think that would increase the frequency of asking users to reauth.
I'm just a little confused about what AI you're implying here.
There was a problem hiding this comment.
What I meant is: You'd double check if this NEEDS_REFRESH is referring to the automatic bearer token refresh that can be done by the JB IDE itself (calling the getToken API) or it is something that requires a full re-auth which requires user input.
There was a problem hiding this comment.
See this code:
When the bearerToken is in the NEEDS_REFRESH state, it can go through tokenProvider.resolveToken() and actually starts to have a new valid bearer token. This is done as long as the user login is valid for about 3 months.
The flow I want to verify is:
Time 0:00: User login, gets a fresh bearer token.
Time 1:00: bearer token expires, BearerTokenAuthState becomes NEEDS_REFRESH state
From 1:00, per 10 seconds, the BearerTokenAuthState should automatically switch from NEEDS_REFRESH state to AUTHORIZED by going through tokenProvider.resolveToken(), even though user does not use the JetBrains IDE. Such that in your PR, the isQExpired can return false and new bearer token can keep being pushed to the Flare.
Otherwise, from time 1:00, BearerTokenAuthState becomes NEEDS_REFRESH state, isQExpired returns true, then no new bearer token will be pushed to Flare, and Flare will make API calls with 4xx.
TLDR: Does this PR work for the case when user login and after one hour of IDE idle (first bearer token expires), Flare can still get the new refresh bearer token and use it to call API?
There was a problem hiding this comment.
Thank you. I added some more logic to my implementation to try and address this.
Qodana Community for JVMIt seems all right 👌 No new problems were found according to the checks applied 💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at qodana-support@jetbrains.com
|
Problem: We are seeing high error rate of ListWorkspaceMetadata ( called by Flare) due to expired bearer tokens in Flare in JetBrains(high chance). This is because the current bearer token sync from IDE to Flare is not robust. In VS Code, we sync bearer token per 10 seconds, in JB, we sync whenever JB bearer token changes. There are edge cases when new fresh bearer token is not up to date in Flare.
Short term solution: In JetBrains, automatically sync bearer token to Flare per 10 seconds or a shorter interval.
Types of changes
Description
Checklist
License
I confirm that my contribution is made under the terms of the Apache 2.0 license.