Azure / Azure/azure-functions-host
Improve detecting host shutdown when invoking functions
- Dominant language
- C#
- Stars
- 2k
- Forks
- 482
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 38
Description
Related to https://github.com/Azure/azure-functions-durable-extension/pull/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.
Contributor guide
Research direction
Start by tracing function.Executor.TryExecuteAsync(...) and the FunctionResult.Exception property, then review the behavior described in PR #2456 and issue #8994. Done means platform failures such as host-shutdown OperationCancelledException can be distinguished from user exceptions, with the intended breaking-change or compatible FunctionResult approach defined for the 5.x/current release.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100