What Is the Process for Subscribing to a Custom Channel with $.emit in Pipedream?

Help
, ,
1

This topic was automatically generated from Slack. You can find the original thread here.

Hi :wave: , I have a couple quick questions RE: Custom Sources $.emit

> name string optional The name of the “channel” you’d like to emit the event to. By default, events are emitted to the default channel. If you set a different channel here, listening sources or workflows can subscribe to events on this channel, running the source or workflow only on events emitted to that channel.
> summary string optional Define a summary to customize the data displayed in the events list to help differentiate events at a glance

  1. How/where can a workflow select the channel to subscribe to? I didn’t see this in the trigger UI. Is there additional config required (I’m editing an HTTP source)
  2. What’s a “listening source”? I haven’t seen this in the docs yet…
  3. I’m setting summary but I don’t see it appear in the list of events on the Source page. Where can it be viewed?
2

Hi, maybe from the Pipedream component dev team can help you in more detail.

He’ll come online in a few hours :pray:

3

Hello , are you trying to emit events received by a webhook?

4

Regarding your questions,

  1. The part you refer to is called Subscriptions, here is the link for the docs
  2. When emitting an event using this.$emit(event, metadata), the metadata parameter is a object that should contain id - any string/number (for deduplication), summary is any string, ts is the timestamp, i.e. new Date(event.date) . So it should look something like this:
this.$emit(event, {
  id: event.id,
  summary: "Event emitted!",
  ts: new Date(event.date),
});

Then whenever this code runs, an event should show up in the events log in the source page

5

Thanks I misread the docs and had amended the event object with summary and name

6

re: (1) Makes sense

7

Hi , I had a bit more trouble after this where including the metedata appears to suppress the event entirely.

After a bit more debugging, it seems that including the name property is the key cause here.

I’m assuming that this means the Source Events UI is subscribing to the default channel and other channels aren’t displayed?

8

Yes, probably

9

I am not sure about that, but I’ve stumbled there before. Had to remove the name property from metadata

10

I originally figured I could use emit channels to handle the 4 different payload types for a Slack interactivity:
https://api.slack.com/interactivity/handling#payloads
… thus keeping the workflows fairly clean.

I’m wondering if you might know of a better path forward?

The other issue I hit is that the ack response from the pipedream source needs to be sent within 3 seconds but this doesn’t always work.

any thoughts you might have are welcome.

11

Let me try to understand, you have one webhook that receives all 4 Slack payload types for interactivity and you want to send each type to a workflow specific for that type?

12

> The other issue I hit is that the ack response from the pipedream source needs to be sent within 3 seconds but this doesn’t always work.
Oh, so this is causing duplicated webhook events?

13

> Let me try to understand, you have one webhook that receives all 4 Slack payload types for interactivity and you want to send each type to a workflow specific for that type?
Exactly.

14

> Oh, so this is causing duplicated webhook events?
No, the slack docs aren’t great but the key timing constraints are:

(1) HTTP response with 200 Ok within 3 seconds.
> All apps must, as a minimum, acknowledge the receipt of a valid interaction payload.
> To do that, your app must reply to the HTTP POST request with an HTTP 200 OK response. This must be sent within 3 seconds of receiving the payload. If your app doesn’t do that, the Slack user who interacted with the app will see an error message. Make sure your app responds quickly.
In some of my early tests, I struggled to achieve this. I know that sometimes workflows take up to 8 seconds extra (presumably lambda cold starts). Not sure where to measure the Source HTTP response times but I did assume some intermittent silent failures are down to this constraint (they might not be.)

(2) publish to a response_url
Can be done up to 5 times within 30 minutes. This is the job of the workflow.

15

I can think of two ways to achieve that:

  1. Using Pipedream Subscriptions - cleaner, but harder.
  2. Using an HTTP source for each the 4 specific payloads workflows, and one workflow with a Slack trigger and a custom Node step that has an if/else that checks for the payload type and sends to the according HTTP endpoint - easier
16

Let me write an example of the Node step

17

makes sense, no need for an example there. is there any difference in the number of paid invocations for those two approaches?

18

I’m guessing it would be the same for both, since I think each triggered event counts as one invocation.
But or @U02A06JPKEH will probably know the exact answer, can one of you help please when you get online?

19

RE: slack timeouts
I think this wouldn’t affect receiving the events in Pipedream, maybe only if slack keeps resending the same event

20

Hi , great question - please see our definition of invocations here:

The Scheduled Workflow section applies to polling based sources.