-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scheduled workflow raising exception: where to observe re-execution? #147
Comments
Hi @chbussler, I think the expectation isn't quite right. A
If you have code like the above then you can observe step_foo() retrying with a warning message printed to the app's log. The design intent is to wrap individual actions (like external API calls) into separate steps. The workflow then proceeds to completion retrying steps only where appropriate. Does this help? |
Hi @apoliakov, thanks for the super-quick response, that's great!
I need a bit more time to make my argument as the system isn't behaving according to my expectations based on the DBOS documentation. I'd like to create one or more use cases around workflows in code so that I can explain what I am trying to address. Please bear with me in this discussion and I'll get back to you. Thank you!
|
The code below shows a scheduled workflow that raises an exception on first execution. In order to identify the executing workflow a log statement logs the workflow id (
sched-print_log-2024-11-05T03:31:50+00:00
).When another workflow is scheduled, it will not raise an exception due to the
workflow_failed
Boolean variable set toTrue
when the first workflow raises an exception.My expectation was that the failed workflow with id
sched-print_log-2024-11-05T03:31:50+00:00
will be re-executed as it did not successfully complete on first execution. Where in the DBOS schema can I observe that the failed workflow is re-executed and successful on 2nd try?Thank you.
Example log:
The text was updated successfully, but these errors were encountered: