Link device in JSON-RPC mode #445
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Looks good - thanks a lot! |
|
Could something like this work for v1/register as well? |
What do you mean exactly? |
|
Sorry, I didn't do enough research on this. You can ignore me. I was trying to get v1/register working. I assumed that it required normal mode. I'm seeing that there just appears to be some ongoing issue with registering numbers. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the link-device functionality previously available in
nativetojson-rpc. As signal-cli requires there to be a second requestfinishLinksent to actually link the device, this runs in a goroutine after the qr code is sent. The goroutine either finishes successfully, or dies after 1 minute due to signal-cli sending a failure message. (the result is available through debug logs).To accomplish this, the
receivedMessageschan had to be modified to actually be a map from "message id" (generated by us) to chan, indexed by the message receiver goroutine when a message is received and deleted after the result is parsed.This is because when there was an ongoing
finishLink"job" running, the chan listener would eat all the other responses, so the service locked up while waiting for messages.Closes #433