Skip to content

Conversation

@satvu
Copy link
Member

@satvu satvu commented May 8, 2023

Related to host issue #9104. Related host PR #9265.

This update allows for retry policy information to be passed through the worker-indexing code path.


// Retry policy which the worker sends the host when the worker indexes
// a function.
message RpcRetryOptions
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Named RpcRetryOptions to avoid confusion with RetryOptions in the host. Precedent set by RpcFunctionMetadata and FunctionMetadata.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So If a function definition is decorated with this information, will the retrycontext populated as part of invocation request will use this info instead of our existing RetryContext prop value (which is populated from host.json?) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder we should rename the prop/type to be more clear that this is something function authors may define on the function level?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The invocation request is created here in GrpcWorkerChannel and the RetryContext field of the invocation request is populated through an extension method here that pulls from an ExecutionContext to get retry information.

I believe the step in ExecutionContext creation that populates retry information is here and pulls from FunctionMetadata, which uses info from RpcRetryOptions. Does that answer your question @kshyju?

Copy link
Member Author

@satvu satvu May 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kshyju While I think it's true that only trigger types that have function-level retry should be using this path, I'm not sure about giving this type a different name (like FunctionLevelRetryOptions) because it's still a representation of the webjobs/host RetryOptions. Also, if we use this type in other ways in the future aside from a reference in RpcFunctionMetadata, it may be more appropriate to have a general name matching with webjobs.

Happy to hear suggestions from others too- it's an easy change at this stage.

As a middle-ground solution I can also revise the comment for this type or add one to the corresponding RpcFunctionMetadata field to give a more detailed explanation of this type and its usage?

Copy link
Member

@brettsam brettsam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm -- but wait for confirmation from other language experts on that Duration usage

@satvu satvu merged commit c91a6cd into dev May 16, 2023
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.

5 participants