Last night, I needed to temporarily prevent incoming real-time messages from continuing through the flow. I therefore intentionally caused them to fail so they would remain in the error queue and could be processed later.
Afterwards, I changed the import setting to “Proceed to the next application regardless” when an import fails. I expected that retrying the failed records would allow them to continue through the remaining steps of the flow. However, when I retry them, they still do not proceed to the next steps.
Why is the retry not using the updated setting? Maybe an idea for a new feature for temporarily parking incoming real-time messages—for example, holding them for one day and then routing them back through the flow—without first storing them on an FTP server?
Hmm something doesn't seem right. If you have "Proceed to the next application regardless" enabled and then something fails, the record continues on, but retrying the failed record later will not send that record through anything other than the step you're on. If you already had failed records, then enabled "Proceed to the next application regardless", I'd expect retries on those errors to proceed along. If the retry fails, then the record should proceed, but any subsequent retries would not. Can you verify?
As far as doing this differently, could you make a 2 flow process? Now that we have Celigo file storage and will have the Celigo APIs connector updated next week (), you could have 1 flow dumping events to storage and then have another flow picking them up on a schedule. This also would help performance to downstream apps by batching requests to them vs single record pages of data.
Thanks for the reply. That is exactly what is not happening in my case. I clicked Retry, but the record did not continue to any of the subsequent steps.
However, when “Proceed to the next application regardless” is enabled, I would expect the record to continue to the next application every time the failed step is retried, regardless of how many times it has already been retried.
Perhaps users should be given two retry options:
Retry only the failed flow step
Retry the failed step and continue to the next application
The second option could be shown only when “Proceed to the next application regardless” is enabled.
), you could have 1 flow dumping events to storage and then have another flow picking them up on a schedule. This also would help performance to downstream apps by batching requests to them vs single record pages of data.