Adding members to group fails silently

[revilo951]

The problem

When attempting to add a member that's not a registered Signal user, the API responds with HTTP 204, the same as when adding a registered Signal user successfully.

With logs set to debug I can see signal-cli does respond with the information like so:

level=debug msg="json-rpc response error: The user +\u2068614********** is not registered."

This really needs to be sent back to the user/application in the http response. At the moment I'm having to parse docker debug logs to catch those errors!

Thanks for an awesome API that's already saving me a lot of time! 🙂

Are you using the latest released version?

• Yes

Have you read the troubleshooting page?

• Yes

What type of installation are you running?

signal-cli-rest-api Docker Container

In which mode are you using the docker container?

json-rpc Mode

What's the architecture of your host system?

x86-64

Additional information

No response

[bbernhard]

Unfortunately, I can't reproduce the issue. Can you please post the obfuscated REST API command you are using.

edit: nevermind, I was using the wrong endpoint.

[bbernhard]

Should be fixed, thanks for reporting!

[revilo951]

Awesome! Will it be in the next release?

[bbernhard]

yes. (If you want to give it a try, you can also use this image: bbernhard/signal-cli-rest-api:1771371761-ci)

[revilo951]

I found that image afterwards, and have tested it. Working perfectly. Thanks for such quick work!

[revilo951]

@bbernhard I believe exactly the same issue exists for adding admins to a group. If you try to add an admin to a group, and they're not already a member of the group, you get back a 204 and nothing happens.

Further to that specifically, should the API add them as a member first, and then promote them to admin? It would save a step in some cases.

[revilo951]

Actually, is it possible to expand on this? Not sure how hard this will be, but here goes.

When adding a number to a group using the cli, it responds with the number, and the UUID of the signal account, like this:

{"results":[{"recipientAddress":{"uuid":"9b2c5cf8-snip","number":"+612snip","username":null},"type":"SUCCESS"}

Is it possible to have the API respond with that info too? Even with an optional flag?

Also, if possible, return the same level of detail when requesting group info? The cli responds like this:

    "members": [
      {
        "number": "+614snip",
        "uuid": "d4d25246-snip"
      }

Reason I ask, is when adding members to groups, sometimes they show in that group with a null number and only the UUID. At the moment the API is only responding with one, or the other, and it makes confirming group membership difficult.

If you want me to open a separate issue for this, just let me know. If I have some time later in the week, I might have a crack at a PR. 😀

[bbernhard]

Sorry, completely missed your message. Shouldn't be too much work - I'll have a look :)

[bbernhard]

Also, if possible, return the same level of detail when requesting group info?

Do you mean in the /groups GET endpoint? I just had a look at the code and it seems that we always pick the number and only fall back to the UUID in case the number is empty/null. So, there shouldn't be any null/empty entry appearing in the pending_invites, pending_requests, admins or members array. But if I understood you correctly, you see this? 🤔

[revilo951]

Do you mean in the /groups GET endpoint?

Yes. I'm not seeing nulls, but I would like to see both the number and the UUID (or have the option to do so).

If I'm trying to track whether a number was added successfully, and whether they have accepted the invite or not, I need the endpoint to respond with at least the UUID of the number I just attempted to add, so I can cover cases when Signal only gives us the UUID, if that makes sense?

Which means when using the /groups GET endpoint, we'll need to have that respond with both the number and the UUID for consistency.

[bbernhard]

Ah, I see. Would it help if there would be a query parameter, which when set, would always return the UUID or would you need both the number and the UUID?

The "problem" with something like this

    "members": [
      {
        "number": "+614snip",
        "uuid": "d4d25246-snip"
      }

is, that this would be an API break and requires a /v2 endpoint. I mean, it's still something we can do, but if we can get away without a new version, I'd prefer it.

[revilo951]

Query param would work perfectly, could probably be used for the same purpose in other endpoints as well if needed?