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?
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?
I haven’t added custom code or code steps to the workflow. It’s a basic workflow using the following triggers and actions:
New record in Airtable (trigger)
Verify email in Verifalia (action)
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.
AN UPDATE:
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.
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.
@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.
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?
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.
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 https://api.pipedream.com/v1/sources/p_BjCpgZx/resume/2D6495zJQIZ22ia7rbmhulBIze5
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
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.
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.
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.
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?