Workflow "Paused"


I have just started using Pipedream and set up my first couple of workflows. During testing, everything works fine. However, when deployed, the flows are getting “paused” after the first step. This has happened with both the workflows I have setup. Does anyone know why this could be happening?


Hi @silisolutionist

That does would weird, perhaps there’s use of $.flow.delay() or $.flow.suspend() somewhere in your workflow?

Could you share more details like which triggers and actions are part of your workflow? If there are any code steps, could you please share the custom code?

Hi @pierce

I haven’t added custom code or code steps to the workflow. It’s a basic workflow using the following triggers and actions:

  1. New record in Airtable (trigger)
  2. Verify email in Verifalia (action)
  3. Update record in Airtable (action)

The only difference between the testing prior to deployment and the deployment setup is that I have used the ‘Standard’ option in Verifalia during testing and then set it to ‘Extreme’ prior to deployment. I was unable to do the pre-deployment test with the ‘Extreme’ setting due to an error message about timeout. I am not sure if this would make a difference.

I just re-tested the workflow with the setting set to ‘Standard’ using a syntatically invalid email address. The workflow is showing under the ‘Deployment’ tab but no data has been sent to the Verifalia account.

Hi @silisolutionist

Turns out yes the Verifalia component is using $.flow.rerun under the hood:

I encourage you to make a bug report here and we can tag the Verifalia developers in the issue.

Hi @pierce

Thanks for looking into this.

I am in communication with Verifalia and they are also following this topic. I will forward to them a screenshot of your message so they can follow up on it. Thanks again.


Hello everybody,

@pierce - not sure why you consider $.flow.rerun() an issue: afaik, the feature has been released a couple of months ago and is stable, please let me know if you were thinking to some specific problem.

@silisolutionist - please try one more time when you can, as explained via email, so that we can track additional data about your attempts and eventually share it with the Pipedream team.

About the update you mentioned: if the trigger did not fire for whatever reason then the Verifalia action did not have a chance to run: you may want to make sure the trigger is firing correctly first.

Thank you.

Hi @verifalia, thanks for joining in the discussion!

not sure why you consider $.flow.rerun() an issue: afaik, the feature has been released a couple of months ago and is stable, please let me know if you were thinking to some specific problem

The first thought is because the @silisolutionist described the workflow as paused. That specific feedback is only when a step is executing the $.flow.delay, $flow.suspend or $.flow.rerun.

The problem was also described as happening on the first step, not trigger, which lead me to opening the component code and seeing the $.flow.rerun use. No saying it’s not a stable feature, just deducing where the problem could be based on what was reported initially.

But @silisolutionist if you could provide the details of the test that @verifalia mentioned outside of this thread that would be very helpful for our troubleshooting.

And can you confirm that Airtable new record events are appearing your workflow’s logs after you deploy?

Thanks, @pierce !

Hi @pierce

While all of the run attempts in the 2 workflows that were deployed yesterday and the day before were showing as “paused”, the runs in 1 of the workflows is now showing as either ‘Executed’ or ‘TypeError’ since an hour ago. The ‘TypeError’ message is “Cannot read property ‘body’ of null (verify_email)”.

The run attempts in the second workflow (with the exact same setup using a diffferent table in the same Airtable base) are still showing as “paused”.

I have gone into the ‘Events’ tab next to ‘Logs’ and clicked on each run and the Airtable data is showing correctly for every run.

The re-testing I did today using the ‘Standard’ setting has also completed in full, finishing with the Airtable record update.

Still got a bunch of runs stuck in Paused on the second workflow. I will now attempt a re-test using the extreme setting.

Ok. I ran the second workflow with the ‘Paused’ runs - with the setting set to ‘Extreme’ - about 7 minutes ago.

The ‘Events’ tab shows the Airtable data but there is nothing showing under ‘Inspector’ or ‘Deployments’.

Thank you: please bear with us while we analyze our log files and try to replicate your scenario.

Here we are: we have analyzed the Verifalia job d47d880a-14b0-4d0b-9954-106203b5a020, which @silisolutionist reported as being stuck in Pipedream, in the Paused status.

Apparently, we have invoked the corresponding Pipedream webhook correctly for that workflow.
Here are our logs:

2022-08-09T02:47:51.401+02:00 Invoking webhook
2022-08-09T02:47:54.801+02:00 Received HTTP status code: 202

But the Pipedream workflow didn’t resume or there is a bug in the Verifalia component.
Could anyone in the Pipedream team help tracking this down, please? @dylburger

Thank you!

Hi @verifalia

From the records in Verifalia, the workflow was run twice even though I added it as a record only once in Airtable - meaning I was charged twice in Verifalia for the same email verification.

The first job ID is b567ee7e-7132-409c-84e2-eec87b840a80. As you can see, it’s the same email address and I suspect after the second run, it has appeared in Inspector as completed.

Unfortunately, I am going to have to discontinue using Pipedream if this issue isn’t sorted.

Hello @silisolutionist,

I believe this is a different, unrelated issue: the Airtable trigger is probably firing too much, not sure why. I encourage you to open a separate request, please.

Also, while we wait for the Pipedream support: please make sure to give them access to the problematic workflow: you can do that through the Settings tab on the workflow editor.

This just means the workflow didn’t resume within the hard timeout of 24 hours we set in the Verifalia component: we would change it to a more meaningful error message but this is a condition we do not expect. I believe we could ignore it, if the Pipedream team figures out what went wrong with the aforementioned failed workflow resumption.

Thank you.

Hi @silisolutionist

I’m still monitoring this thread - could you share the workflow event ID that you suspect to have ran twice?

The event ID can be found by clicking the specific event in the workflow inspector, then looking in the URL of your browser. It should be at the very end.

Hi @pierce

Here’s the event ID - 2D6494OikP4OY0cFzCY1rvzLxbe

I’ve given them access to both workflows which I have Paused to avoid incurring credits in Verifalia.

Thanks @silisolutionist

Which workflow in particular is this event ID associated with?

No worries @pierce

It’s associated with the ‘New Apollo Airtable Records to Verifalia Email Validation’ workflow.

Perfect, thanks @silisolutionist

I believe I may have spotted the Paused workflow issue on this Apollo Airtable sourced workflow.

Could you please try copying the workflow and trying again?

Reuse your corresponding Airtable source from the first workflow so that you’re not running the same records again:

CleanShot 2022-08-09 at 13.55.43@2x

Still not certain of the double email submission, from my end I see what you see, that each Airtable record was only emitted once from your source.

Is it possible that you have duplicate records across your 2 different Airtable bases?

I have checked the email address in both tables and it exists in only one. Further, I only submitted the one record in total yesterday when we were testing.

I have copied the workflow but the trigger is missing.

I am not sure what this means. Do I need to set up the trigger again on the copied workflow?