conversations_invite() fails with "error: no_user"

[noperator]

TL;DR: Until a few hours ago, the SDK function conversations_invite() used to succeed with no issues. Now, it fails with error: no_user. It seems that the users argument to the conversations.invite API method may have changed to require a JSON array (rather than a comma-separated string), so conversations_invite() may need to be updated accordingly. CC: @tracertea

Reproducible in:

The Slack SDK version

$ pip freeze | grep slack
slack-bolt==1.6.1
slack-sdk==3.7.0

Python runtime version

$ python --version
Python 3.9.5

OS info

$ sw_vers && uname -v
ProductName:    macOS
ProductVersion: 11.2.3
BuildVersion:   20D91
Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64

Steps to reproduce:

Attempt to invite a user to a channel via conversations_invite(), passing the following arguments:

• channel (str): The channel ID
• users (str or list): A list of user IDs to invite

Note that if conversations_invite() is passed users as a list (i.e., rather than str—both types are indicated to be valid), it will collapse that list into a comma-separated str, which is consistent with Slack's API documentation for the conversations.invite method's users argument:

A comma separated list of user IDs. Example:
W1234567890,U2345678901,U3456789012

Surprisingly, this will fail:

channel = 'C1234567890'
users = ['U2345678901']

client.conversations_invite(channel=channel, users=users)
# "ok": false, "error": "no_user"

However, if we instead bypass conversations_invite() and directly call the conversations.invite method so that users is not collapsed into a comma-separated str and is passed directly as a list, the call succeeds:

channel = 'C1234567890'
users = ['U2345678901']

client.api_call(
    "conversations.invite",
    json={"channel": channel, "users": users},
)
# "ok": true

Expected result:

Expected a successful response from the conversations.invite API method:

{
  "ok": true,
  "channel": {
    "id": "[REDACTED]",
    "name": "[REDACTED]",
    "is_channel": true,
    "is_group": false,
    "is_im": false,
    "created": ["REDACTED"],
    "is_archived": false,
    "is_general": false,
    "unlinked": 0,
    "name_normalized": "[REDACTED]",
    "is_shared": false,
    "parent_conversation": null,
    "creator": "[REDACTED]",
    "is_ext_shared": false,
    "is_org_shared": false,
    "shared_team_ids": [
      "[REDACTED]"
    ],
    "pending_shared": [],
    "pending_connected_team_ids": [],
    "is_pending_ext_shared": false,
    "is_member": true,
    "is_private": true,
    "is_mpim": false,
    "last_read": "[REDACTED]",
    "is_open": true,
    "topic": {
      "value": "",
      "creator": "",
      "last_set": 0
    },
    "purpose": {
      "value": "",
      "creator": "",
      "last_set": 0
    }
  }
}

Actual result:

We get an error indicating that "No value was passed for users":

{
  "ok": false,
  "error": "no_user"
}

[misscoded]

Hi @noperator -- thanks for taking the time to bring this to our attention!

This is actually a bug on the SDK side of things: one we overlooked when sequence support was introduced. We'll work on getting a PR out to fix it. Thanks again for reporting it 🙂

[seratch]

Hi @noperator, thanks again for taking the time to report this. I was going to fix this issue but I found that the current implementation does work without any issues.

"error": "no_user"

This error indicates the situation where no users value is passed in the API call. With this SDK, the code should be like this:

client.conversations_invite(channel=channel_id, users=None)

Perhaps, the users in your code might be None for some reason. Let us know if you are facing a different pattern.

[noperator]

At this point, it seems clear that this is/was an issue with Slack's conversations.invite API method, rather than the conversations_invite() SDK function which in turn invoked the API method.

To summarize the core issue that I reported yesterday: Slack's conversations.invite API method was failing when we'd pass users as a (comma-separated) JSON string ("U2345678901"), rather than wrapping that value in a JSON array (["U2345678901"]) which would succeed.

Perhaps, the users in your code might be None for some reason

Totally—that was the first thing we ruled out yesterday. Here's how the conversations.invite API method would respond with various types of input for its users argument:

• null: no_user
• "U2345678901": no_user (this should have worked)
• ["U2345678901"]: ok

the current implementation does work without any issues

Okay—just tested conversations.invite and can confirm that it's now succeeding when users is of type string or array, vs. yesterday when it'd only succeed with an array.

It seems like this was an unintended "blip" in JSON types that conversations.invite would accept for its users argument. I suppose at this point that this issue is outside the scope of Python Slack SDK—but just to thoroughly document what we experienced here for future reference, here's a simple example using cURL that I captured yesterday while we were still experiencing this issue.

Passing users as a string would fail:

curl \
    --request 'POST' \
    --url 'https://slack.com/api/conversations.invite' \
    --header 'Authorization: Bearer <TOKEN>' \
    --header 'Content-Type: application/json; charset=utf-8' \
    --data '{
        "channel": "C1234567890",
        "users":   "U2345678901"
    }'

# {
#   "ok": false,
#   "error": "no_user"
# }

But passing users as an array would succeed:

curl \
    --request 'POST' \
    --url 'https://slack.com/api/conversations.invite' \
    --header 'Authorization: Bearer <TOKEN>' \
    --header 'Content-Type: application/json; charset=utf-8' \
    --data '{
        "channel": "C1234567890",
        "users":   ["U2345678901"]
    }'

# {
#   "ok": true,
#   "channel": {
#     [...]
#     }
#   }
# }

Will follow up shortly with some quick testing just to ensure the conversations_invite() SDK function works on our end (i.e., in addition to testing the conversations.invite API method which seems to be working now). Thanks @seratch.

[seratch]

@noperator Thanks for sharing more details! I will come up with a pull request to eliminate this issue with a few API methods.