Fix OpenApp failures due to expired authToken#11151
Conversation
…ticate. no need to try to prevent reauthentication attempts
My best idea for how to achieve this is to just set up a local promise to hook other reauthenticate requests into and ensure we are only ever re-authenticating once. Like... function reauthenticate(commandName) {
if (isAuthenticating) {
return isAuthenticating;
}
isAuthenticating = Authentication.reauthenticate(commandName)
.then((response) => {
isAuthenticating = null;
return response;
});
return isAuthenticating;
} |
|
It worked pretty good |
|
That worked really well 😄 |
luacmartins
left a comment
There was a problem hiding this comment.
LGTM and tests well!
|
|
@ctkochan22 I'm gonna hit the merge on this one so we can scratch this off the list, but lmk if you spot anything that needs to be addressed. |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by @marcaaron in version: 1.2.5-0 🚀
|
|
🚀 Deployed to production by @luacmartins in version: 1.2.5-2 🚀
|

cc @luacmartins
Details
This is kind of a quick fix, but I think in the longer term we will want to:
Here's the basic logic behind this PR...
READrequests andmakeRequestWithSideEffectswere originally envisioned to be non-retryable requestsreadormakeRequestWithSideEffectsfailsmakeRequestWithSideEffectswe'll want the original response returned so we will chain them like we do requests in the sequential queuereadthen we will reauthenticate but not call the original request directly and instead trigger the reconnection callbacks so that any registered fetchData() calls can be updated now that we have the new authToken from the authenticate response.Weird stuff...
I also noticed that some writes that started after read requests failed because they also require re-authentication. It didn't make sense that we would encounter that situation before since two writes can't possibly happen simultaneously and reauthentication is blocking in the sequential queue.
I think it would be fairly safe to just remove that logic and if we are already reauthenticating then just let another reauthentication happen. So that's my general plan for this.
Fixed Issues
$ #11081
Tests
ReconnectAppeventually returns 200 jsonCodePR Review Checklist
Contributor (PR Author) Checklist
### Fixed Issuessection aboveTestssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*filesSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */displayNamepropertythisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)Avataris modified, I verified thatAvataris working as expected in all cases)PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed
### Fixed Issuessection aboveTestssectionQA stepssectiontoggleReportand notonIconClick).src/languages/*filesSTYLE.md) were followedAvatar, I verified the components usingAvatarhave been tested & I retested again)/** comment above it */displayNamepropertythisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)Avataris modified, I verified thatAvataris working as expected in all cases)QA Steps
Screenshots
Web
Mobile Web - Chrome
Mobile Web - Safari
Desktop
iOS
Android