Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Fix error documentation typos and enum values #1276

Merged
merged 1 commit into from
Oct 26, 2023
Merged

Fix error documentation typos and enum values #1276

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 19 additions & 20 deletions internal/error.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,12 +44,12 @@ and actual error which caused activity failure. This internal error can be unwra
Below are the possible types of internal error:
1) *ApplicationError: (this should be the most common one)
*ApplicationError can be returned in two cases:
- If activity implementation returns *ApplicationError by using NewApplicationError() API.
The err would contain a message, details, and NonRetryable flag. Workflow code could check this flag and details to determine
what kind of error it was and take actions based on it. The details is encoded payload which workflow code could extract
to strong typed variable. Workflow code needs to know what the types of the encoded details are before extracting them.
- If activity implementation returns *ApplicationError by using NewApplicationError()/NewNonRetryableApplicationError() API.
The error would contain a message and optional details. Workflow code could extract details to string typed variable, determine
what kind of error it was, and take actions based on it. The details are encoded payload therefore, workflow code needs to know what
the types of the encoded details are before extracting them.
- If activity implementation returns errors other than from NewApplicationError() API. In this case GetOriginalType()
will return original type of an error represented as string. Workflow code could check this type to determine what kind of error it was
will return original type of error represented as string. Workflow code could check this type to determine what kind of error it was
and take actions based on the type. These errors are retryable by default, unless error type is specified in retry policy.
2) *CanceledError:
If activity was canceled, internal error will be an instance of *CanceledError. When activity cancels itself by
Expand All @@ -59,19 +59,18 @@ Below are the possible types of internal error:
details about what type of timeout it was.
4) *PanicError:
If activity code panic while executing, temporal activity worker will report it as activity failure to temporal server.
The SDK will present that failure as *PanicError. The err contains a string representation of the panic message and
The SDK will present that failure as *PanicError. The error contains a string representation of the panic message and
the call stack when panic was happen.

Workflow code could handle errors based on different types of error. Below is sample code of how error handling looks like.

err := workflow.ExecuteActivity(ctx, MyActivity, ...).Get(ctx, nil)
if err != nil {
var applicationErr *ApplicationError
if errors.As(err, &applicationError) {
// retrieve error message
fmt.Println(applicationError.Error())

// handle activity errors (created via NewApplicationError() API)
if !applicationErr.NonRetryable() {
// manually retry activity
}
var detailMsg string // assuming activity return error by NewApplicationError("message", true, "string details")
applicationErr.Details(&detailMsg) // extract strong typed details

Expand All @@ -95,12 +94,12 @@ if err != nil {
if errors.As(err, &timeoutErr) {
// handle timeout, could check timeout type by timeoutErr.TimeoutType()
switch err.TimeoutType() {
case commonpb.ScheduleToStart:
// Handle ScheduleToStart timeout.
case commonpb.StartToClose:
// Handle StartToClose timeout.
case commonpb.Heartbeat:
// Handle heartbeat timeout.
case enumspb.TIMEOUT_TYPE_SCHEDULE_TO_START:
// Handle ScheduleToStart timeout.
case enumspb.TIMEOUT_TYPE_START_TO_CLOSE:
// Handle StartToClose timeout.
case enumspb.TIMEOUT_TYPE_HEARTBEAT:
// Handle heartbeat timeout.
default:
}
}
Expand All @@ -110,13 +109,13 @@ if err != nil {
// handle panic, message and stack trace are available by panicErr.Error() and panicErr.StackTrace()
}
}

Errors from child workflow should be handled in a similar way, except that instance of *ChildWorkflowExecutionError is returned to
workflow code. It will contains *ActivityError, which in turn will contains on of the errors above.
workflow code. It might contain *ActivityError in case if error comes from activity (which in turn will contain on of the errors above),
or *ApplicationError in case if error comes from child workflow itself.

When panic happen in workflow implementation code, SDK catches that panic and causing the workflow task timeout.
That workflow task will be retried at a later time (with exponential backoff retry intervals).

Workflow consumers will get an instance of *WorkflowExecutionError. This error will contains one of errors above.
Workflow consumers will get an instance of *WorkflowExecutionError. This error will contain one of errors above.
*/

type (
Expand Down
22 changes: 11 additions & 11 deletions temporal/error.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,10 +41,10 @@ Below are the possible types of internal error:
*ApplicationError can be returned in two cases:
- If activity implementation returns *ApplicationError by using NewApplicationError()/NewNonRetryableApplicationError() API.
The error would contain a message and optional details. Workflow code could extract details to string typed variable, determine
what kind of error it was, and take actions based on it. The details is encoded payload therefore, workflow code needs to know what
what kind of error it was, and take actions based on it. The details are encoded payload therefore, workflow code needs to know what
the types of the encoded details are before extracting them.
- If activity implementation returns errors other than from NewApplicationError() API. In this case GetOriginalType()
will return orginal type of an error represented as string. Workflow code could check this type to determine what kind of error it was
will return original type of error represented as string. Workflow code could check this type to determine what kind of error it was
and take actions based on the type. These errors are retryable by default, unless error type is specified in retry policy.
2) *CanceledError:
If activity was canceled, internal error will be an instance of *CanceledError. When activity cancels itself by
Expand All @@ -54,7 +54,7 @@ Below are the possible types of internal error:
details about what type of timeout it was.
4) *PanicError:
If activity code panic while executing, temporal activity worker will report it as activity failure to temporal server.
The SDK will present that failure as *PanicError. The err contains a string representation of the panic message and
The SDK will present that failure as *PanicError. The error contains a string representation of the panic message and
the call stack when panic was happen.
Workflow code could handle errors based on different types of error. Below is sample code of how error handling looks like.

Expand Down Expand Up @@ -89,12 +89,12 @@ if err != nil {
if errors.As(err, &timeoutErr) {
// handle timeout, could check timeout type by timeoutErr.TimeoutType()
switch err.TimeoutType() {
case commonpb.ScheduleToStart:
// Handle ScheduleToStart timeout.
case commonpb.StartToClose:
// Handle StartToClose timeout.
case commonpb.Heartbeat:
// Handle heartbeat timeout.
case enumspb.TIMEOUT_TYPE_SCHEDULE_TO_START:
// Handle ScheduleToStart timeout.
case enumspb.TIMEOUT_TYPE_START_TO_CLOSE:
// Handle StartToClose timeout.
case enumspb.TIMEOUT_TYPE_HEARTBEAT:
// Handle heartbeat timeout.
default:
}
}
Expand All @@ -106,11 +106,11 @@ if err != nil {
}
Errors from child workflow should be handled in a similar way, except that instance of *ChildWorkflowExecutionError is returned to
workflow code. It might contain *ActivityError in case if error comes from activity (which in turn will contain on of the errors above),
or *ApplicationError in case if error comes from child workflow itslef.
or *ApplicationError in case if error comes from child workflow itself.

When panic happen in workflow implementation code, SDK catches that panic and causing the workflow task timeout.
That workflow task will be retried at a later time (with exponential backoff retry intervals).
Workflow consumers will get an instance of *WorkflowExecutionError. This error will contains one of errors above.
Workflow consumers will get an instance of *WorkflowExecutionError. This error will contain one of errors above.
*/

type (
Expand Down
Loading