Garion,
If you call this microflow from another microflow, you can add error processing on the sub-microflow. I think this will catch any unexpected errors.
From a 'best practices' standpoint, if time allows, I would consider re-architecting the microflow so there is one generation action if possible (or fewer than there are currently) so you can capture the error where it happens and handle it from there.
Also, maybe consider using a logging entity since this microflow is running in a task queue. Then you can capture any generated errors and review them after they occur.
Hope that helps,
Mike
I would suggest you to break the microflow into meaningful parts and wrap them inside another microflow. While calling the submicroflows, set error handling to "Custom with Roll-back" (or Custom without Roll-back if you believe failing that particular microflow does not need DB roll-back).
In the error handling part, you can call an error reporting microflow by providing inputs $latestError and the your original input entity. The error reporting writes a log to console and as well as a persistable ErrorLog entity which you can show in the Admin panel.
Add a status flag for Failed alongside Pending and Ready.
Put the PDF/Excel logic in a sub-microflow with custom error handling → if it errors, update the request to Failed and store/log the message.
This gives the admin immediate visibility without relying on timeouts.