Subscription Listener Not Receiving Workflow Emits

Help
1

I am trying to subscribe one workflow to events emitted by another workflow, but my listener isn’t receiving any events.

I made an API call to subscribe the listener to the emitter and got a successful response with a subscription id.

I ran my emitter workflow and saw that it’s emitting events:
image

However, when I look at the listening workflow, it has not received any new events.

I was having an issue where my newly-created subscription would disappear from the list returned by the Get Current User’s Subscriptions API after a few minutes, but that might be a separate issue. It seems to be fixed now that I’ve changed my listening workflow’s source from a Scheduled source to a HTTP/Webhook source per this thread: Subscription listener keeps getting removed from workflow after deploy.

But I’m still stuck trying to figure out how to get my listening workflow to receive events from my emitting workflow. I double-checked the workflow IDs that I used for the subscription to make sure they were correct and I used the Get Workflow Emits API to confirm that my emitter is in fact emitting the events. Now I’m stumped.

I have testing workflows I can share if anyone wants to take a look and help me troubleshoot.

2

@CelesteBancosHP Thank you for reporting. I’ll take a look ASAP.

3

@dylburger Any updates on this subscription issue?

Let me know if you want me to share the workflows I’ve been using to test this out.

4

@CelesteBancosHP I apologize for the delay looking into this. Yes, could you share the workflow emitting events, and the workflow you’ve configured as a listener, with dylan@pipedream.com?

And just to confirm, does the subscription work for a time, until you redeploy the listener workflow? Or does the subscription never work? Now that you’ve setup the listener with the HTTP / Webhook source as its main trigger, do you see the subscription successfully listed in the Get Current User’s Subscription’s endpoint after you create it? I’m mainly trying to understand the conditions where it works, and when it fails.

5

Ok, workflows shared with you.

So far I have never gotten the subscription to work, though it does show up in the Get Current User’s Subscription’s list.

6

Thanks. I do see the listener configured on the backend. But I also see that the emitted events aren’t being sent to that listener. I created the exactly same setup as you (cron-triggered $send.emits, listener workflow with an HTTP / Webhook source, enabled the HTP / Webhook source as a listener in the workflow), and ran the following command to create the subscription:

curl 'https://api.pipedream.com/v1/subscriptions?emitter_id=p_OKCOybZ&listener_id=p_o7CAQ3b' \
  -X POST \
  -H "Authorization: Bearer XXX" \
  -H "Content-Type: application/json"

That worked for me, and the subscription still stuck around after multiple deploys.

I noticed that the subscription you created had an event_name of default. Did you happen to pass that when creating the subscription? Either way, I removed the subscription on the backend to reset things. Would you mind trying to create the subscription one more time, as in my example, and see if the listener receives emitted events?

1 Like
7

I tried my Subscription workflow again, but this time I took out the part that sets event_name to default, and now it’s working; thank you!

I had been using default as the event name based on the Subscriptions documentation but I guess that’s incorrect? I see that it’s listed as optional in the documentation page, but I didn’t think including it would cause any issues. But maybe I’m misunderstanding what the event name is for.

8

@CelesteBancosHP That was actually my mistake, the docs were incorrect. event_name=default will fail, as you noted. You should leave event_name out completely. I’ve corrected the docs.

Appreciate you raising this.

1 Like