-
Notifications
You must be signed in to change notification settings - Fork 275
add additional python error handling details from course #3855
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good additions; just did a little wordsmithing.
``` | ||
|
||
Depending on your implementation, you may decide to use either method. | ||
One reason to use the Temporal `ApplicationError` class is because it allows you to set an additional `non_retryable` parameter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One reason to use the Temporal `ApplicationError` class is because it allows you to set an additional `non_retryable` parameter. | |
An additional reason to use the Temporal `ApplicationError` class is because it allows you to set an additional `non_retryable` parameter. |
Suggested this change since you already gave one valid reason; so this is another.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmm, did I already give another reason?
|
||
## Failing Workflows {#workflow-failure} | ||
|
||
One of the core design principles of Temporal is that an Activity Failure will never directly cause a Workflow Failure — a Workflow should never return as Failed unless deliberately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the core design principles of Temporal is that an Activity Failure will never directly cause a Workflow Failure — a Workflow should never return as Failed unless deliberately. | |
One of the core design principles of Temporal is that an Activity Failure will never directly cause a Workflow Failure — a Workflow should never return as Failed unless it is deliberately returned that way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmm. Good pointing out this wasn't clear, can we just change "deliberately" to "intentional"? Fewer words.
) from e | ||
``` | ||
|
||
You can alternately specify a list of errors that are non-retryable in your Activity [Retry Policy](#activity-retries). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick code sample for this here would be nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is anchored down to the rest of the same doc, I didn't want to overload it here.
|
||
This works differently in a Workflow than raising exceptions from Activities. | ||
In an Activity, any Python exceptions or custom exceptions are converted to a Temporal `ApplicationError`. | ||
In a Workflow, any exceptions that are raised other than an explicit Temporal `ApplicationError` will only fail that particular [Workflow Task](https://docs.temporal.io/tasks#workflow-task-execution) and be retried. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be good to specifically mention:
- the difference between a Workflow Task Failure vs Workflow Execution Failure. I know you're doing this here, but calling it Workflow Task Failure might help people understand this error when it appears in the Web UI.
- Also that Workflow Task Failures retry by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personal bias, but imo I think trying to explain "Workflow Task vs Workflow Execution" gets really into the weeds (it's my least favorite aspect of the actual course right now), and I deliberately tried to avoid that here. A Workflow Task is a very marginal aspect of most people's understanding of Temporal, I want to keep the emphasis on "retry" vs "return".
Added some missing context from the error handling course to explain Activity vs Workflow Failures and Non-Retryable Errors. This should be ported to the other languages if we like it (and note that Go works a bit differently than the others).