Closed m-natarajan closed 2 weeks ago
Triggered auto assignment to @lschurr (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
Job added to Upwork: https://www.upwork.com/jobs/~0140408c8876b6a1dd
Triggered auto assignment to Contributor-plus team member for initial proposal review - @alitoshmatov (External
)
Just add a page reload once user's SSO signIn is done. That will do the job.
📣 @nitinigi2! 📣 Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork. Please follow these steps:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>
Hi @alitoshmatov - Can you take a looksie at this one?
Reproduced, couldn't find root cause yet
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
Any update @alitoshmatov? Are we just waiting for proposals?
Yes waiting for proposals here
Still waiting on proposals.
Still waiting on proposals.
@lschurr @alitoshmatov this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
Hi, I’m Michael (Mykhailo) from Callstack and I would like to work on this issue.
Hey! I confirm that the bug is replicable. Moreover, the bug repeats for Apple SSO as well.
I've investigated data that the app gets from the backend for the SignInWithGoogle
and SignInWithApple
commands. Actually, there is a huge difference between responses for SigninUser
and SSO. The backend does not return reports and many other data.
There are 2 obvious solutions:
OpenApp
or ReconnectApp
right after the authorization has happened.I read contributingGuides/APPLE_GOOGLE_SIGNIN.md. I've not found any info that this type of authorization omits some data to send to the app. Also, it requires some additional configs to test the development mode due to the SSO restrictions. However, it is not required here, because I assume the bug should be fixed on the backend side.
So we need an internal engineer to help with the issue.
@alitoshmatov - what do you think?
@lschurr, @alitoshmatov Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Not sure why the Overdue persists. Bump here @alitoshmatov
@rezkiy37 @alitoshmatov - Do we also need to make this internal?
📣 @alitoshmatov 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!
@rezkiy37 @alitoshmatov - Do we also need to make this internal?
Looks like yes.
Sorry for late response.
Yes we need internal engineer here based on @rezkiy37 observation
Added Internal here to find an engineer to work on this.
No update on this one.
Asked in Slack - https://expensify.slack.com/archives/C066HJM2CAZ/p1717084703979449
Bumped the Slack thread.
No update.
Still don't have an internal eng volunteer.
Asking in newdot-quality: https://expensify.slack.com/archives/C05LX9D6E07/p1718293036755239
@rezkiy37 It has been a while but can you take a look at it again: reports data is being received with openApp
request, any idea why it is not being applied?
Yes, I can confirm that the bug no longer exists.
https://github.com/Expensify/App/assets/57314631/6e3144c7-7005-46b9-a972-8ac43e162e5b https://github.com/Expensify/App/assets/57314631/badc98d8-f607-42e9-a211-637ba5800ee9
cc @lschurr
Ah, perfect thanks! Closing.
@rezkiy37 I think you missed couple of steps to reproduce. It is still reproducible for me. I was just sharing my finding here
https://github.com/Expensify/App/assets/59907218/4bf97842-dc40-402b-bcc6-b24bf1bbbe8b
cc: @lschurr
Ah, exactly. My bad. Let's reopen the issue. Seems like the app should call OpenApp for this scenario.
I've found out why the app does not show much data alongside reports.
The app calls OpenApp right after Google or Apple authorization. However, the app initially calls ReconnectApp. It sets lastUpdateID
from the very beginning. It is 438474121
in my case. The OpenApp response has lastUpdateID
as well. It is 438465717
.
There is a condition in how the app checks whether it should apply new coming onyx data. It compares the current lastUpdateID
with the last one.
As we can see above, if there was an update with greater lastUpdateID
, the app omits onyxData.
Therefore we can see that the OpenApp's lastUpdateID
is less when ReconnectApp's lastUpdateID
.
438465717 < 438474121 // true
The app does not take Onyx data into account.
Regarding this comment - https://github.com/Expensify/App/issues/41246#issuecomment-2168447420. I tested with the primary login page. The app does not call ReconnectApp from the very beginning on the login page. That's why the app applies OpenApp's Onyx data.
Please re-open the issue 🙂
cc @alitoshmatov @lschurr
Thank you @rezkiy37 for pretty in-depth explanation 👍, that makes sense. @lschurr Looks like we do need internal engineer after all, since we have problem with backend response.
Bumped the Slack thread - https://expensify.slack.com/archives/C05LX9D6E07/p1718293036755239
Still need an engineer here.
Triggered auto assignment to @flodnv (AutoAssignerNewDotQuality
)
I read the issue, and I don't understand why this needs to be Internal. Can we get an external contributor to work on it?
@flodnv, because it requires changes on the backend side.
Right, I read your comment 3 times and I'm sorry but I still don't understand which change we need on the backend side. If you had access to the backend code, what change would you make? Or maybe you can present this in a Problem/Solution form so I can understand better?
Well, lastUpdateID
comes from the backend. This value is deprecated for this scenario. So the backend should increment it correctly. Does it make sense?
@flodnv I think the main issue we are struggling here is that even though reconnectApp
is called first it is getting higher lastUpdateID
then openApp
request which is called after this and its changes are not applied due to its lower lastUpdateID
. These lastUpdateID
s are issued from backend. I think naturally request order should also reflect lastUpdateID
.
Maybe there is a race condition going on?
Okay, thanks for the (re)explanation, I can look into that. My first step is obviously to reproduce myself.
Go to staging on Chrome - log out if you need to Access public room - staging.new.expensify.com/r/2376199970894587 Navigate to the self DM that populates in LHN
Note: I don't see a self DM.
Click ‘Sign in’ in the banner Sign in w/ Google
I was able to reproduce though.
@rezkiy37 @alitoshmatov do we call the same set of APIs (in the same order) from the App when signing in via Google as when signing in via magic code in this specific flow? It's surprising to me that this bug only exists on Google Signin.
the app initially calls ReconnectApp
I tested a few times watching the network console and I do not see a call to ReconnectApp
However, I do see 2 calls to OpenApp. @rezkiy37 @alitoshmatov what are your thoughts?
@flodnv, it does call ReconnectApp for me on the dev, but it does not call on the staging. So I tried to test the staging and what I found. There is an OpenReport response that has the same lastUpdateID
as OpenApp has. This OpenReport has been called before and sets its own lastUpdateID
. The next OpenApp is skipped due to the condition:
Does it make sense now?
Any update here @alitoshmatov @flodnv?
Just bumping again for an update @alitoshmatov @flodnv :)
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Version Number: 1.4.67-2 Reproducible in staging?: Yes Reproducible in production?: yes If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: @garrettmknight Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1714391455919649
Action Performed:
Expected Result:
Your signed in profile’s chats load
Actual Result:
No additional chats load, ‘Hmm…’ flashes
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/38435837/faf8e560-0869-4fd9-b9ab-f7ac8ed5156a
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @cristipaval