search

hoehermann / purple-signald

Pidgin libpurple bridge to signald.
GNU General Public License v3.0
153 stars 19 forks source link

Bad response: 429 with libpurple-signald #40

Closed heywoodlh closed 3 years ago

heywoodlh commented 3 years ago

I am running Bitlbee-libpurple and signald in Docker containers. The bitlbee-libpurple container builds libpurple-signald from source so I should be on the latest version of libpurple-signald.

I am running into an issue that when I attempt to turn on the hehoe-signald account through Bitlbee via libpurple-signald then Bitlbee crashes.

Specifically when I execute account hehoe-signald on, Bitlbee crashes.

I get the following error logs from signald:

18:26:15.656 [main] INFO  io.finn.signald.Main - Binding to socket /signald/signald.sock
18:26:15.708 [main] INFO  io.finn.signald.Main - Started signald 0.12.0+git2021-02-08r98148393.17
18:27:14.102 [socketlistener] INFO  io.finn.signald.SocketHandler - Client connected
18:27:15.171 [socketlistener] INFO  manager-**********30 - Creating new manager for **********30 (stored at /signald)
18:27:17.096 [socketlistener] INFO  manager - Created a manager for **********30
18:27:17.184 [socketlistener] ERROR io.finn.signald.SocketHandler - Catching
org.whispersystems.signalservice.api.push.exceptions.NonSuccessfulResponseCodeException: Bad response: 429 
        at org.whispersystems.signalservice.internal.push.PushServiceSocket.validateServiceResponse(PushServiceSocket.java:1477) ~[signal-service-java-x86_64-unknown-linux-gnu-2.15.3_unofficial_17.jar:?]
        at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceRequest(PushServiceSocket.java:1435) ~[signal-service-java-x86_64-unknown-linux-gnu-2.15.3_unofficial_17.jar:?]
        at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceBodyRequest(PushServiceSocket.java:1420) ~[signal-service-java-x86_64-unknown-linux-gnu-2.15.3_unofficial_17.jar:?]
        at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceRequest(PushServiceSocket.java:1362) ~[signal-service-java-x86_64-unknown-linux-gnu-2.15.3_unofficial_17.jar:?]
        at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceRequest(PushServiceSocket.java:1338) ~[signal-service-java-x86_64-unknown-linux-gnu-2.15.3_unofficial_17.jar:?]
        at org.whispersystems.signalservice.internal.push.PushServiceSocket.getContactTokenDetails(PushServiceSocket.java:782) ~[signal-service-java-x86_64-unknown-linux-gnu-2.15.3_unofficial_17.jar:?]
        at org.whispersystems.signalservice.api.SignalServiceAccountManager.getContact(SignalServiceAccountManager.java:364) ~[signal-service-java-x86_64-unknown-linux-gnu-2.15.3_unofficial_17.jar:?]
        at io.finn.signald.Manager.getUser(Manager.java:1511) ~[signald.jar:unspecified]
        at io.finn.signald.SocketHandler.getUser(SocketHandler.java:574) ~[signald.jar:unspecified]
        at io.finn.signald.SocketHandler.handleRequest(SocketHandler.java:214) [signald.jar:unspecified]
        at io.finn.signald.SocketHandler.run(SocketHandler.java:132) [signald.jar:unspecified]
        at java.lang.Thread.run(Unknown Source) [?:?]
18:27:17.342 [socketlistener] INFO  io.finn.signald.SocketHandler - Client disconnected
18:27:17.343 [socketlistener] INFO  io.finn.signald.MessageReceiver - Last client for **********30 unsubscribed, shutting down message pipe!

I can send a message using the signald.sock socket file that is running in the finn/signald container from my Bitlbee container:

[root@arch-oryx ~]# docker exec -it bitlbee bash
bash-5.0$ nc -U /var/run/signald/signald.sock
{"type":"version","data":{"name":"signald","version":"0.12.0+git2021-02-08r98148393.17","branch":"main","commit":"9814839376b0aceed8329fecc7477a5da7d0cae8"}}
{"type": "send", "username": "+1********30", "recipientAddress": {"number": "+1********30"}, "messageBody": "Testing"}
{"type":"send_results","data":[]}

(FYI I just sent a test message to myself) ^^

I'm able to send and receive my message using netcat without issue:

image

Since I'm able to interface with the signald.sock socket file without issue from my Bitlbee container this looks to me like an implementation issue with libpurple-signald.

I would greatly appreciate any suggestions on how to fix this issue! :D

heywoodlh commented 3 years ago

For reference I also submitted an issue at the signald repository: https://gitlab.com/signald/signald/-/issues/126

hoehermann commented 3 years ago

Thank you for your report. Whatever happens there, an error in signald should not make the plug-in crash. I want to see if I can reproduce this in Pidgin.

Note: I recently stopped using this plug-in for myself since tinkering around with the sister-project purple-signal is more interesting. Hence I miss many bugs unless they are reported.

hoehermann commented 3 years ago

I am unable to reproduce this problem with Pidgin on Ubuntu. I am using the same version of signald, but I cannot forcibly trigger the "NonSuccessfulResponseCodeException" easily. Can you turn on debug logging in bitlbee? On Pidgin, this is done with the -d switch. Everything signald-related between got newline delimited message: {"type":"version","data":{"name":"signald","version":"0.12.0…"}} and the crash would be useful.

thefinn93 commented 3 years ago

ahh I think know what this is. It seems like this is an issue with libpurple-signald calling get_user too frequently. That hits a heavily rate limited endpoint, it seems. Here's another report of the same thing that said they would raise it here but I don't think actually did. Is there some reason libpurple-signald is calling get_user?

ps. I consider the stack trace and bad error message to be a signald issue and intend to fix that at least

hoehermann commented 3 years ago

Hi Finn, thank you for being with me. I have no idea where that might come from. get_user is not even mentioned in the code.

thefinn93 commented 3 years ago

Indeed... looks like it was removed a month ago. I wonder if both of these reports are just from users on an older version of the plugin? I'm debugging with @heywoodlh on IRC right now.

hoehermann commented 3 years ago

Possible, but unlikely. The request for get_user was done once (after subscribing). That should not trigger any rate-limiting, should it not? Unless I had some other issue going on back then which caused the plug-in to unsubscribe and re-subscribe rapidly.

thefinn93 commented 3 years ago

@heywoodlh reports on IRC that they were using this Dockerfile, which runs git checkout af18341 (a commit from July 2020) before building. Trying to rebuild with the latest master now.

heywoodlh commented 3 years ago

@hoehermann I didn't notice that git checkout line. I modified the Dockerfile and now I'm using master. Everything seems to be working properly using master. Sorry for the wild goose chase!

I'll submit a PR to https://github.com/ezkrg/docker-bitlbee-libpurple and modify the Dockerfile to just use master.

hoehermann commented 3 years ago

All good. If possible, chose the most recent tag instead. If that is not an option, using master is okay. Sometimes I break stuff. :|

heywoodlh commented 3 years ago

Pull request has been submitted: https://github.com/ezkrg/docker-bitlbee-libpurple/pull/20

Zauberfisch commented 3 years ago

Just had the same issue with a package from AUR. Uninstalling the package and building libpurple-signald from source fixed the problem for me.