Fix proto documentation for next_retry_delay field #426
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cretz
approved these changes
Jun 28, 2024
| 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.
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
| "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.
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.
yiminc
approved these changes
Jul 1, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removed the note in the doc which is not true anymore. The
next_retry_delayfield is handled when a workflow task produces a failure including it (Implemented in temporalio/temporal#5946)