Subscription listener keeps getting removed from workflow after deploy

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

Trever Faden : Hey Team - The listener I’m placing on a workflow (for an emit event on a different workflow) keeps dropping for some reason. (meaning, emitter is emitting but listener isn’t picking up the event). Once I “re-subscribe” the listener, it works…but seems to cut off after 24-48 hours.

Dylan Sather (Pipedream) : Hi , what’s the main trigger (separate from the subscription) on this workflow? e.g. are you using the HTTP API trigger?

Trever Faden : $send.emit

Trever Faden : from a workflow

Trever Faden : no event name, just a json object with a raw_event key

Dylan Sather (Pipedream) : Would you mind clicking the Share button in the top-right of the listening workflow and share it with dylan@pipedream.com?

Trever Faden : yep! I just swapped it out the emitter for a $send.http to make sure they were sent but i’ll invite you now

Dylan Sather (Pipedream) : Great thanks. There’s a known issue that’s affecting you here where we’ll drop subscriptions when you deploy a workflow, only when you’re using a “native” workflow trigger like HTTP.

Triggering the workflow via $send.http() like you are now should work fine. Or, you could delete the main HTTP trigger on your workflow by clicking the x in the top-right corner of the trigger step, then select one of the HTTP / Webhook event sources from the trigger menu. When your workflow is triggered by an event source, you can add as many additional subscriptions as you’d like, and they shouldn’t be wiped on deploy.

We plan to address this in a future release, so hopefully it won’t bite you again in the future

Trever Faden : Ah! Super helpful! Thanks !