slackapi / deno-slack-sdk

SDK for building Run on Slack apps using Deno
https://api.slack.com/automation
151 stars 27 forks source link

[QUERY] no more than 20 items allowed [json-pointer:/event/channel_ids] #305

Closed bevans-HD closed 2 months ago

bevans-HD commented 3 months ago

Question

Can the event tigger channel_ids max be increased from 20? If not, what is the maximum number of triggers allowed in a workflow?

Context

I created a simple app that needs to watch for a text pattern in a lot of channels. Like 100+ channels. I wrote code to dynamically create and update triggers based on the configurator example in one of the slack sample apps. Up until yesterday I was happily adding channel_ids to existing triggers like so:

      // channelIds is a list of current channels plus a new one 
        MessagePostedTrigger.event.channel_ids = channelIds;

        const updateWorkflowTrigger = await client.workflows.triggers
          .update({ trigger_id: trigger.id, ...MessagePostedTrigger });
        if (!updateWorkflowTrigger.ok) {
          console.log("DEBUG: updateWorkflowTrigger");
          console.log(updateWorkflowTrigger);
          throw new TriggerOperationError(
            updateWorkflowTrigger?.error,
            `Failed to update MessagePostedTrigger: ${trigger.id}`,
          );
        }
      }

Well I found out the hard way there is a limit of 20 channels allowed in the event trigger:

{
  toFetchResponse: [Function: toFetchResponse],
  ok: false,
  error: "invalid_arguments",
  response_metadata: {
    messages: [
      "[ERROR] no more than 20 items allowed [json-pointer:/event/channel_ids]"
    ]
  }
}

If this is a hard limit, what do you suggest I do watch for a text pattern in 100's of channels? Create an event trigger per-channel? Any guidance would be appreciated.

Thank you

Environment

cat import_map.json | grep deno-slack
    "deno-slack-sdk/": "https://deno.land/x/deno_slack_sdk@2.9.0/",
    "deno-slack-api/": "https://deno.land/x/deno_slack_api@2.3.2/",
deno --version
deno 1.38.4 (release, x86_64-apple-darwin)
v8 12.0.267.1
typescript 5.2.
sw_vers && uname -v
ProductName:        macOS
ProductVersion:     14.4.1
BuildVersion:       23E224
Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

seratch commented 3 months ago

Hi @bevans-HD, thanks for asking the question!

Indeed, up-to-20 channel in a single event trigger is a limitation the platform has. To deal with it, there are two options:

  1. Create one more trigger with a different set of channels for the same event
  2. Enable all_resources: true option and remove channel_ids from the definition.

I'd sugest the second one because it'll be far easier to manage. I wrote a blog post on the option yesterday. I hope you find it helpful: https://dev.to/seratch/slack-automation-no-more-hardcoding-channelids-for-event-triggers-4d5b

bevans-HD commented 2 months ago

Wow, how fortuitous. Option 2 looks perfect. I found the limit while prepping for the official internal release of the bot. Looks like I'll be able to just rip out all the channel_ids and "configurator" code before unleashing the bot & explaining to everyone the whole /configure process.

Thank you @seratch! I can report back after I've migrated to all_resources: true

filmaj commented 2 months ago

@bevans-HD One thing worth considering is the potential cost implications of having unfiltered channel event triggers firing off workflows; if these workflows are considered Premium, you may incur an additional charge. Using a hard-coded list of channel_ids is one way to control that more finely. Just wanted to point that out!

filmaj commented 2 months ago

I will close this issue as it seems it has been resolved, but if there is anything else here feel free to re-open or open a new issue.

bevans-HD commented 2 months ago

It is resolved. Using all_resources: true allowed me to remove all the configurator code and made managing my workflows much easier. Thanks again!