Correctly map all Error fields from gRPC details
It's not enough to just return the correct error type. User logic, not to mention client internals, rely on specific fields from the error returned by the server. Extract these from the Status details and set them on the corresponding TException type.
Additionally include the Client feature flags header, which can disable/enable returning WorkflowExecutionAlreadyCompletedError. The current implementation incorrectly translated EntityNotExistsErrors to WorkflowExecutionAlreadyCompletedError based on the message name, which is different from the Thrift behavior. If the client sends the correct header it will receive the correct type.
What changed?
- Populate Error fields when using gRPC
- Include FeatureFlags headers on gRPC requests
Why?
- User code may rely on these fields
- Client internals, such as polling for Workflow completion with global replication, rely on these fields.
- FeatureFlags control whether some error types are returned to the client
How did you test it?
- Unit and integration tests
Potential risks
Release notes
Documentation Changes