Cannot send messages: too many retries

[an0nfunc]

Login works, but as soon as someone tries to send messages, the bridge just returns:

WRN Got rate limited action="send content" chat_id=<id> event_id=<event_id> event_type=m.room.message portal_chat_id=<portal_chat_id> recipient=<recp> response_id=14 response_status=428 retry_after_seconds=86400 room_id=<roomid> timestamp=<stamp>
ERR sendContent too many retries action="send content" chat_id=<id> event_id=<event_id> event_type=m.room.message portal_chat_id=<portal_chat_id> recipient=<recp>response_id=14 response_status=428 retry_count=4 oom_id=<roomid> timestamp=<stamp>

Not sure what to do here, since this seems like rate limiting from signals side. I only have a few users, and signal is not very busy, not sure where the rate limit would come from. It's persistent over a few weeks now, no sending possible. Receiving works just fine.

[mjw3428]

I have this issue too. It would be good if the error handling sent the challenge token back to the user so that they could submit a rate limit challenge.

If the bridge supported sending a rate limit challenge that would also be useful.

[tchernobog]

I just moved to the go bridge implementation and this prevents me to send any message.

Does anybody know how what is causing this, or how to work around it without installing the official Signal App?

@tulir did you ever see this before?

[an0nfunc]

Just a quick update: Currently it seems to work for me, but I have not changed anything afaik.

[tommes0815]

I do see the same issue and the same log messages (rate limiting) although not for all messages. It happens since I switched from the old to the go based bridge. I use signal-cli as my main device. All messages sent to contacts I have not rceived messages from for a couple of months are effected. Messages to contacts I received lately messages from work properly.

[tillmannwolter]

I also get "error": "too many retries" from Signal. It turns out that Signal blocks all outbound messages that are initiated using the bridge/integration. Outbound messages are allowed, once a message from another party is received using the bridge/integration. Maybe some kind of SPAM protection? It is just very confusing for the user when getting the "error": "too many retries". Maybe s.o. knows if that is standard behavior from Signal that could be nicely be reworded by Beeper?

[an0nfunc]

Just to say that this is still an issue, but now the bridge will not even tell you (in portal chat) that sending has failed. Latest git version.

ERR Failed to handle Matrix message error="too many retries" action="handle matrix event" event_type=m.room.message portal_id=<portal-id> portal_mxid=<mxid>

[maltee1]

It's signal doing the ratelimiting. Since the bridge can't send push challenges, you'll experience this more frequently than on an official app (for me almost every time I send a message to an new contact).

You can't really do anything to fix that afaik. You can work around it by sending a message from an official signal client first (it might ask you to complete a captcha). I will probably soon-ish rebase #510 , which will allow you to work around the problem entirely from a matrix client, in case that's a concern. I will also try to remember adding a proper error message that tells you what to do.

[an0nfunc]

@maltee1 I actually just saw your PR and I'm currently rebasing it and giving it a try.

edit: Okay, it seems to be working, at least in principle, as I am now getting

WRN Got rate limited action="send content" event_type=m.room.message portal_id=<portal-Id> portal_mxid=<mxid> recipient=<rcpt> response_id=6 response_status=428 retry_after_seconds=86400 timestamp=1723316557281
ERR Failed to handle Matrix message error="captcha challenge required" action="handle matrix event" event_type=m.room.message portal_id=<pid> portal_mxid=<mxid>

edit2: Seems like I lost the command part in the rebase. I'll add that back and report back.

[maltee1]

The bridge got upgraded to v2 in the meantime, so commands work slightly differently now and they go elsewhere.

[an0nfunc]

The bridge got upgraded to v2 in the meantime, so commands work slightly differently now and they go elsewhere.

Yeah, I noticed that :grin:

I rebased in on the latest tag, lets see how that goes. nvm, the db was already migrated of course.