-
Notifications
You must be signed in to change notification settings - Fork 991
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
fix_: ignore log partial API request #21312
Conversation
Jenkins BuildsClick to see older builds (4)
|
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.
@qfrank, shouldn't this mobile PR use all the new *V2
endpoints you created in the status-go PR? Otherwise, doing QA in this mobile PR won't validate the new endpoints work.
Another way to frame my question is, why did we create V2 functions if status-mobile is the only consumer of the functions in mobile/status.go
? Why keep V1 and V2 versions if we only need to point to the V2 ones?
If this mobile PR changed to use the new V2 endpoints:
- We would QA only once, thus no need for a follow-up.
- We would be able to remove all deprecated functions in
mobile/status.go
.
Maybe I'm missing something and there's a good reason to keep deprecated and v2 functions in mobile/status.go
.
It depends on time, I thought we should fix the issue quickly, WDYT?🤔 cc @churik We can create separate PR to use all the new *V2 endpoints and validating then.
create V2 should keep application stable, status-mobile is NOT the only consumer of the functions in mobile/status.go, desktop also use it. |
6f08f86
to
bc9f76d
Compare
Thanks for the clarification. I think we could at least use the V2 endpoints on the mobile repo in this PR. It thought it was just a matter of renaming in mobile in a handful of places because V2 functions are backwards compatible. But this is just my personal preference, if you and QA team think it's alright to have a follow-up no worries by me. |
It's easy for you but not for me. Merely renaming and constructing JSON request parameters. I doubt that it will be completed in a short time for me under strict clojure coding rules 😉. If someone(clojure expert) can help, that's another story |
No worries then @qfrank. To each their own cup of tea 😄 PR more than approved, it's just that QAs should be aware they won't be testing some of the new code being merged in status-go, as that will come only in the follow-up PR using new endpoints. I would like to help, but realistically I'll probably just cause a delay on the process due to other tasks on me already. |
@qfrank @ilmotta From my side I don't have an info where particular methods can be used in the app, so I checked:
I didn't notice any sensitive info (i.e. passwords) in Let me know if additional check are required. |
yes
no more from my side, thank you! |
86% of end-end tests have passed
Failed tests (7)Click to expandClass TestActivityMultipleDevicePR:
Class TestOneToOneChatMultipleSharedDevicesNewUi:
Class TestCommunityMultipleDeviceMerged:
Class TestWalletMultipleDevice:
Class TestGroupChatMultipleDeviceMergedNewUI:
Passed tests (44)Click to expandClass TestOneToOneChatMultipleSharedDevicesNewUiTwo:
Class TestOneToOneChatMultipleSharedDevicesNewUi:
Class TestCommunityOneDeviceMerged:
Class TestActivityCenterContactRequestMultipleDevicePR:
Class TestWalletMultipleDevice:
Class TestActivityMultipleDevicePRTwo:
Class TestDeepLinksOneDevice:
Class TestCommunityMultipleDeviceMergedTwo:
Class TestCommunityMultipleDeviceMerged:
Class TestGroupChatMultipleDeviceMergedNewUI:
Class TestWalletOneDevice:
|
57% of end-end tests have passed
Failed tests (3)Click to expandClass TestWalletMultipleDevice:
Class TestCommunityMultipleDeviceMerged:
Passed tests (4)Click to expandClass TestActivityMultipleDevicePR:
Class TestGroupChatMultipleDeviceMergedNewUI:
Class TestCommunityMultipleDeviceMerged:
Class TestOneToOneChatMultipleSharedDevicesNewUi:
|
e2e test failures are not related, green light, thanks! |
bc9f76d
to
bcc8f05
Compare
For change description see details
relate comment1 / comment2
status: ready.