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

Improve detecting host shutdown when invoking functions #9233

Open
jviau opened this issue Apr 26, 2023 · 0 comments
Open

Improve detecting host shutdown when invoking functions #9233

jviau opened this issue Apr 26, 2023 · 0 comments

Comments

@jviau
Copy link
Contributor

jviau commented Apr 26, 2023

Related to Azure/azure-functions-durable-extension#2456

Issue

The above issue was caused by an incorrect assumption that function.Executor.TryExecuteAsync(...) would throw on host shutdown (primarily because we supplied the host shutdown cancellation token). This is not the case, instead the function invocation will 'complete' in a failed state. This led to durable extension to not retry all these triggered functions (orchestrations and activities in this case) on host shutdown, instead it considered them complete/failed.

Suggestion

I think it would be a better experience for us to differentiate platform exceptions from user exceptions here. User exceptions can continue to be swallowed and exposed in the function results .Exception property. Platform exceptions, including host shutdown OperationCancelledException, can be bubbled up directly. This will give callers an explicit way to essentially 'abort' their invocation in the case of host shutdown or other transient platform issues.

While this does violate the Try* pattern, I believe being able to easily distinguish platform error vs user error is worth the trade-off. This would be a behavior breaking change and need to go into 5.x.

This would also help address #8994

Alternative Suggestion

We improve the FunctionResult object to include enough information to differentiate platform from user error. An enumeration property describing the cause (ie Platform / User) may be sufficient. This would not be a breaking change and could go into the current release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants