-
Notifications
You must be signed in to change notification settings - Fork 65
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
Fix proto documentation for next_retry_delay field #426
Conversation
@@ -3295,7 +3293,21 @@ components: | |||
encodedAttributes: | |||
allOf: | |||
- $ref: '#/components/schemas/Payload' | |||
description: "Alternative way to supply `message` and `stack_trace` and possibly other attributes, used for encryption of\n errors originating in user code which might contain sensitive information.\n The `encoded_attributes` Payload could represent any serializable object, e.g. JSON object or a `Failure` proto\n message.\n\n SDK authors: \n - The SDK should provide a default `encodeFailureAttributes` and `decodeFailureAttributes` implementation that:\n - Uses a JSON object to represent `{ message, stack_trace }`.\n - Overwrites the original message with \"Encoded failure\" to indicate that more information could be extracted.\n - Overwrites the original stack_trace with an empty string.\n - The resulting JSON object is converted to Payload using the default PayloadConverter and should be processed\n by the user-provided PayloadCodec\n\n - If there's demand, we could allow overriding the default SDK implementation to encode other opaque Failure attributes." | |||
description: |- |
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.
Neat, TIL the OpenAPI generator will use escaped-string YAML if there is trailing space in the comment which makes sense I guess since multiline-YAML trims it I suppose
@@ -3725,7 +3725,7 @@ | |||
}, | |||
"nextRetryDelay": { | |||
"type": "string", | |||
"description": "next_retry_delay can be used by the client to override the activity\nretry interval calculated by the retry policy. Retry attempts will\nstill be subject to the maximum retries limit and total time limit\ndefined by the policy.\nATTENTION: this value will be ignored if set for failures produced by\nthe workflow." | |||
"description": "next_retry_delay can be used by the client to override the activity\nretry interval calculated by the retry policy. Retry attempts will\nstill be subject to the maximum retries limit and total time limit\ndefined by the policy." |
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.
You can call the maximum retries limit the "Maximum Attempts", see https://docs.temporal.io/encyclopedia/retry-policies#custom-retry-policy
The total time limit for activities is called the "Schedule to Close timeout"
https://docs.temporal.io/encyclopedia/detecting-activity-failures#schedule-to-close-timeout and for a workflow it's the execution timeout. https://docs.temporal.io/encyclopedia/detecting-workflow-failures#workflow-execution-timeout
The timeouts are not on "the policy"; they are separate.
Removed the note in the doc which is not true anymore. The
next_retry_delay
field is handled when a workflow task produces a failure including it (Implemented in temporalio/temporal#5946)