This topic was automatically generated from Slack. You can find the original thread here.
Hello, I am experiencing repeated problems where HTTP GET/POST requests sent to the “Resume URL” of a suspended workflow do not resume the workflow.
We have been experiencing that problem for months.
Our current workaround is to send multiple requests in a row to the resume URL.
It’s pretty harmless as the extra requests will simply get ignored, since the workflow can’t be resumed more than once.
The response doesn’t provide a valid status of if the resume worked or not (it just says “resume requested” even if it failed), so currently we send 5 requests in a row, and it seems to have fixed the problem.
The same problem also happens with $.flow.rerun() (i.e. sometimes one of the reruns doesn’t start/resume).
In those cases, we use the data store and a monitoring workflow to detect reruns that are not happening when they should, and we call the resume URL (from the data store) to force the rerun to resume.
Got it. I was also thinking of sending multiple requests to the resume URL, but wanted to check here first. Thanks for your help.
I’ll follow up on this to see where we are with it
It could be helpful to offer a different/alternative interface than HTTP, since this is internal to Pipedream. So we could have a function that is able to communicate with the Pipedream internals via $.flow.resume() instead of going through HTTP. And then that method could provide a more detailed response.
This would also remove the need for resume URLs, since we could resume based on the invocation trace_id instead.
I’ve mentioned that in this thread, but haven’t had time to make an official feature request yet.