-
Notifications
You must be signed in to change notification settings - Fork 248
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!: leftovers work for sync fallback #5794
Conversation
Thank you for opening this pull request! Looks like you have BREAKING CHANGES in your PR. |
Jenkins BuildsClick to see older builds (50)
|
9c847bb
to
837f682
Compare
cc @glitchminer looks like this is a good case for some user stories 🙂 |
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.
Looks good, though more than half the code is mine 🙈
@qfrank do you want to address Igor's comments or do you want me to do it?
nvm I did it :D
I added a commit with the review comment fixes. I also rebased and updated my status-desktop PR here: status-im/status-desktop#15820 It works again as expected |
@qfrank @jrainville are you still around this PR? |
8eea23b
to
da30cca
Compare
updated @igor-sirotin |
@qfrank feel free to squash my commits if you want |
1b4176c
to
b501c88
Compare
Needed for status-im/status-desktop#15750 Adds an AC notification when the syncing fails and the user is prompted to use a seed phrase instead. There is one notification for the initiator (created) and one for the old account (received). Once the flow is completed, ie the receiver presses Enable and sync, the notifications are deleted
b501c88
to
016595b
Compare
Hi @qfrank, rebased the PR - status-im/status-mobile#21090 (comment) |
@@ -1063,8 +1063,8 @@ func (api *PublicAPI) SyncDevices(ctx context.Context, name, picture string) err | |||
return api.service.messenger.SyncDevices(ctx, name, picture, nil) | |||
} | |||
|
|||
func (api *PublicAPI) EnableAndSyncInstallation(request *requests.EnableAndSyncInstallation) error { | |||
return api.service.messenger.EnableAndSyncInstallation(request) | |||
func (api *PublicAPI) EnableInstallationAndSync(request *requests.EnableInstallationAndSync) (*protocol.MessengerResponse, error) { |
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.
As I understand, this is the only breaking change in this PR.
If you really think we should rename it, then:
- Mark
EnableAndSyncInstallation
as deprecated, but keep it working. - Introduce
EnableInstallationAndSync
and update clients to use the new endpoint.
This way we can ensure clients are still compatible with the changes.
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'm not fully aware of all the implications, but as I understood it, the breaking change it bigger than that. Once this is released, people will only be able to pair between 2.31 and up.
I guess it was not possible to keep backwards compatibility, otherwise Andrea would have thought of it.
As for renaming the API, both desktop and mobile are creating PRs at the same time, so I think it's fine to just rip the band aid right now and not keep an unused API?
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 think it depends on the terminology of a breaking change
that we should agree upon.
Let me discuss this with the @status-im/status-go-guild today, I'll be back with an answer in the evening.
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.
We have 3 types of breaking change:
- Breaking between versions (the type that we want to avoid the most)
- Breaking of functionality (basically introducing a (or several) bug(s))
- Breaking between
status-go
and client (potentially this case)
I think breaks between status-go
and clients can be managed, as long as they are managed they are only a problem if someone has an old branch and doesn't rebase against the latest develop
.
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 have added the old API back, can I get your approval now? 🙂 Your approval is valuable for me! @igor-sirotin
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 I'm not really saying that we should stick to the old function name.
But there's a way to make this carefully: create a new function and deprecate the old one. Then the switch to the new function name will be seamless 🙌
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.
create a new function and deprecate the old one
I've done this yesterday 🙂
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.
Can I merge it now? I'm waiting for your approval 🥹 @igor-sirotin
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.
Oh! I only read your comment and and didn't check the code 😄
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.
no worries, we can create another PR if needed
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.
Thank you @qfrank , I've gone through this and it all seems really nicely written.
This is a continue work to PR
2 Major changes in this PR:
relate mobile PR