-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Make OpenApp a write command #37062
Make OpenApp a write command #37062
Conversation
Seems we'd need to update the unit test cases and types too |
Yeah I'm looking into it now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory, I am not a fan of this change. I think it blurs the lines between why something is a read/write in the first place. If something is being made a read/write only to have some kind of effect in the UI, and it is not based on the command actually "reading or writing" to the database, then I think it's an indication that we are doing something wrong.
Since it sounds like the real intention is to have OpenApp go into the synchronous blocking queue, I'd be much more in favor of us opening up an option for that so that we can be explicit that this is still a READ command, but the request needs to go into the synchronous queue for X reason.
@tgolen I agree and I thought about that, but
It's still a bit blurry for me what exactly the reason is, but I'll try to figure it out again today so we can be confident about this change. |
OK, thanks! That's great if |
reconnectApp is a write command??? What does it write? |
I'm not sure, if it doesn't actually write anything, it seems like we made it a write solely to have it block the queue? cc @tgolen I can see it was added here. Also cc'ing @danieldoglas as you might have context as well |
The design doc said:
"It will call `API.write` (doing this so that it blocks all other calls)"
So yeah, I think your assumption is correct. No wonder why I didn't like
manipulating read/write like that!
…On Thu, Feb 22, 2024 at 1:08 PM Youssef Lourayad ***@***.***> wrote:
reconnectApp is a write command??? What does it write?
I'm not sure, if it doesn't actually write anything, it seems like we made
it solely to have it block the queue? cc @tgolen
<https://github.com/tgolen> I can see it was added here
<#23516>
—
Reply to this email directly, view it on GitHub
<#37062 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJMAB2ECJFK2PIMR3WPSCDYU6QTLAVCNFSM6AAAAABDUEGEPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQGIYDONBQHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Can someone exlpain why ReconnectApp needs to block other calls? I can understand it for OpenApp but not for ReconnectApp. |
App.openApp(); | ||
App.openApp(); | ||
App.openApp(); | ||
PersonalDetails.openPersonalDetails(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to use a READ command here to make the test pass. It seems like this behaves differently when we call a write command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this scenario though of a write command with an expired authToken and I was re-authenticated properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please update the comment above here that says "make 3 API requests" to specifically say that they are READ requests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On it.
App.openApp(); | ||
App.openApp(); | ||
App.openApp(); | ||
PersonalDetails.openPersonalDetails(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please update the comment above here that says "make 3 API requests" to specifically say that they are READ requests?
cc'ing @marcaaron as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes seem fine as far as I understand them. The "skew" stuff I am not sure about tbh still need to catch up on why we added that.
@@ -31,7 +31,7 @@ let cancellationController = new AbortController(); | |||
/** | |||
* The API commands that require the skew calculation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably unrelated, but I am completely confused about what a "skew calculation" refers to here. I see these changes, but did not have an opportunity to make sense of them yet.
@@ -101,8 +101,7 @@ describe('NetworkTests', () => { | |||
); | |||
|
|||
// This should first trigger re-authentication and then a Failed to fetch | |||
App.confirmReadyToOpenApp(); | |||
App.openApp(); | |||
PersonalDetails.openPersonalDetails(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see we just picked a flow arbitrarily to confirm the re-auth behavior? Looks good!
Looks like we just need a checklist, since this is hard to reproduce on mobile, I think we can just do web screenshots. |
Reviewer Checklist
Screenshots/VideosAndroid: NativeAndroid: mWeb ChromeiOS: NativeiOS: mWeb SafariMacOS: Chrome / SafariScreen.Recording.2024-02-27.at.5.42.37.p.m.movMacOS: Desktop |
✋ 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 https://github.com/marcochavezf in version: 1.4.45-0 🚀
|
🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.45-6 🚀
|
cc @iwiznia @tgolen @roryabraham @marcochavezf
Details
This PR makes OpenApp a write command so that for anonymous users we make sure to process
OpenApp
first before any requests that are made after it.Summary of my findings from this thread
Fixed Issues
$ #36430
Tests
sleep(3)
toopenApp
here, as to reproduce this bugOpenReport
needs to finish beforeOpenApp
.Offline tests
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)/** comment above it */
this
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
Screen.Recording.2024-02-21.at.23.10.24.mov
MacOS: Desktop