Then you can select your previously made Airtable source for that base you already set up.
One last theory on the duplicate email issue - is it possible you used that Airtable record when you were building and testing your workflow?
Testing doesn’t prevent duplicate runs of the same event by design. Is it possible you tested that Verifalia step more than once or your entire workflow after testing the Verifalia step?
Ok, this is done. Should I be testing the workflow within the Edit screen or after Deployment? Within the Edit screen, I am unable to test with the ‘Extreme’ setting - it only seems to work with the ‘Standard’ setting which kind of defeats the purpose.
If you want me to run the workflow post-deployment on the ‘Extreme’ without testing it within the Edit screen, I would prefer to use a different email address so I am not incurring validation creadits on the same email again.
Nope. I have made sure to use a different record every single time to avoid confusion.
What I meant when I said ‘testing’ is that I ran the workflow post-deployment - it was run only once when requested to yesterday - if not, I wouldn’t have brought it up in the first place.
Ok, this is done. Should I be testing the workflow within the Edit screen or after Deployment?
In this case, since the Verifalia component uses $.flow.rerun under the hood, you’ll have to test after deployment.
This is because the action actually pauses the entire workflow until Verifalia responds by requesting a specific URL provided by Pipedream.
$.flow.rerun doesn’t actually pause the workflow in building or testing mode, so Verifalia may have received the email address and processed it, but you wouldn’t have seen the results in the builder.
If you want me to run the workflow post-deployment on the ‘Extreme’ without testing it within the Edit screen, I would prefer to use a different email address so I am not incurring validation creadits on the same email again.
Sure, whatever makes the most sense for you to test. If you want to wait for an organic new record, we can stand by.
Ok. I have deployed the workflow with the ‘Extreme’ setting without testing it pre-deployment. Yesterday I had click on ‘Run Now’ for testing purposes. I shall leave it this time to run in its own time - new record added to the Airtable.
I updated the Airtable with a larger set of records and while 16 out of 17 of them were processed successfully, 1 of them is stuck in Paused mode again - event ID 2D8VyUW4Oih8guUiE6pZEy33xlG.
UPDATE
I think I have figured out what is causing one record in every run to get stuck in Pause mode - these are the first records in every run (first record of second set - Event ID 2D8q2ZTTJ7ZcTdjxupIp3i8ZU7M.
could you please let us have the Verifalia job IDs (you can find them on your Verifalia dashboard) which appear to be still processing in Pipedream, so that we can double-check the related resumption URL has been called correctly on our logs?
our logs show that the Pipedream resumption URL took more than 5s, which is our maximum allowed timeout, to reply to our webhook request.
@pierce would it be possible to speed up the resumption callback processing speed, please?
@silisolutionist we have extended the timeout for Pipedream callbacks in the meantime, so that you should not experience any stuck workflow anymore. Please let us know if you still do or if you have any other question or issue.
Glad we were able to pinpoint it - could you share the resume URL for that recent timeout case? It sounds like a cold start issue but I want to double check with the team.
According to our logs, it has been invoked at 2022-08-09T23:36:15.156+02:00 and by 2022-08-09T23:36:22.176+02:00 it wasn’t yet completed and that resulted in a timeout.
@verifalia I looked into our logs and the initial request never appeared to make it to our load balancer. We log all requests here, whether they fail due to being blocked by our firewall (that shouldn’t be the case here, and we would return a 403 error), if the load balancer fails to send the request to the target backend service, etc. Since we never received the request, the timeout would make sense and it’s possible something happened at some intermediate hop.
Let us know if you have other resume / cancel URLs for which this is the case and we can look into it. In general there is nothing in this specific service that would wait on resources to run or other heavy I/O. We just queue the resume / cancel call and should return a 202 quickly.
@dylburger we are not sure about what may have caused that issue but have extended our timeout and reprocessing logic since then, just to take into account this possible problem.
@silisolutionist please let us know if you still encounter random issues of this type: we are actively monitoring our logs and dlq just to make sure everything is running fine now - we would be grateful to you if you could kindly confirm all is well on your end too.
I have processed 3 large batches since my last message. The first two batches were processed without any issues. However, a batch I just put through has an issue with one of the records submitted. When logged in to Verifalia, it looks like it is stuck in ‘Processing’ mode (image attached).
The Pipedream event ID is 2DgJzZIaacdULGWIX94FoDXl3NM.
Verifalia Job no. is: 13bba6bf-8d7c-4edc-bbc3-01571cb5cf0f
@silisolutionist Would you mind visiting your workflow’s Settings and share the workflow with Pipedream support? I’d like to take a look at the execution logs for that event if you don’t mind.
Thanks for sharing. It looks like that event expired from the event history (given the default limits we apply on the free tier), so I can’t see the ID associated with the resume_url, which I would need to see if a request was made to our endpoint. If @verifalia logged this request URL, I can look at our logs to see if a request was made and if we failed to process it for some reason.
