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.

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

Merged
merged 1 commit into from
Jul 1, 2024

Conversation

gow
Copy link
Contributor

@gow gow commented Jun 27, 2024

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)

@gow gow enabled auto-merge (squash) June 27, 2024 23:13
@@ -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: |-
Copy link
Member

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."
Copy link

@drewhoskins-temporal drewhoskins-temporal Jun 29, 2024

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.

@gow gow merged commit 80d141c into master Jul 1, 2024
3 checks passed
@gow gow deleted the cg_next_retry_delay branch July 1, 2024 04:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants