This topic was automatically generated from Slack. You can find the original thread here.
i’d like to retry the latest workflow event via API. What’s the API for this?
Currently, Pipedream does not provide a direct API to replay workflow events programmatically. However, you can list the most recent 100 workflow errors using the Pipedream REST API and manually replay them if needed. Here’s how you can list the errors: bash curl 'https://api.pipedream.com/v1/workflows/p_abc123/$errors/event_summaries?expand=event' \ -H 'Authorization: Bearer <api_key>' This command will return the full error data, along with the original event that triggered your workflow. You can then manually replay the event by sending an HTTP request with the data found in event.original_event. For more details, you can refer to the Pipedream documentation. If you need further assistance, please visit Pipedream Support.
can we get an API to replay workflow events? There’s a unique fire-and-forget usecase i have for this, except in the event that it does error in a separate system (but succeeded idempotently in Pipedream) and I’d need the event to replay in Pipedream
Would auto-retry work? Or $.flow.rerun to handle that specific request? GitHub
ehhh i could, although that keeps that workflow running while it polls I guess
that doesn’t, we suspend and execute the workflow again when the retry is specified
it may be acceptable if the external job is short-running, but in a long-running case it becomes a long wait time
ohh
interesting
auto-retry also suspends and executes the execution again at the next retry window, only on the step that fails
k, i’ll implement it this way then
thanks!
nice, yeah let me know if that doesn’t end up working!
for $.flow.rerun(DELAY, null, MAX_RETRIES);, if the max retries is set to 3, and it succeeds on the 1st or 2nd retry attempt, i’m assuming then that the 3rd doesn’t run, right?
When you manually use $.flow.rerun, you’d need to handle the continuation logic yourself. So in this example, we only do the rerun in the catch case, so in your example, if the request succeeds, it would move to the next step and never hit the $.flow.rerun case
but otherwise if it keeps hitting that catch block and running $.flow.rerun, it would continue until MAX_RETRIES (for that specific workflow event)
okay, so the $.flow.rerun is workflow event ID aware so that, in the event that the error keeps happening and the catch triggers, it’ll do it only until the max retries limit?
and of course if it succeeds and never catches, it just never fires off that rerun call again
that’s exactly right