Conversation
| // The error message will be duplicated if the `failure` field is present to support callers that pre-date the | ||
| // addition of that field. |
There was a problem hiding this comment.
| // The error message will be duplicated if the `failure` field is present to support callers that pre-date the | |
| // addition of that field. | |
| // The error message may be totally or partially redundant with the `failure` field, if present, to support callers that pre-date the | |
| // addition of that field. |
I can imagine that, if this feature is supported, SDK might allow for a sensitive-information-free message separate from the full details.
There was a problem hiding this comment.
Yeah, in which case the failure message will be the same as error_message (e.g. "Encoded...") and the sensitive information will be in the encoded details.
There was a problem hiding this comment.
👍 For SDK implementers worker side, error_message is expected to always be set to failure.message. And for SDK implementers client side, error_message should be ignored if failure is non-null. But yes, both error_message and failure.message will have "Encoded failure" for encoded failures (and client side since error_message is ignored when failure is present, the failure should be decoded and the decoded failure message would be used).
There was a problem hiding this comment.
What I meant is that it might make sense to allow setting error_message to something different, if we want to allow for specifying some un-encoded message.
But, regardless, if the expectation is that, any time failure is used, the message is always just "Encoded failure" or w/e, then we should specify that in the docstrings too.
## What changed? Attach a Failure object from query failures to the QueryFailure serviceerror. ## Why? Allows encryption of failure messages and stack traces. See also temporalio/api/pull/503.
What changed?
Add a
Failurefield to:Why?
Support encoding failure attributes for E2E encryption of messages and stack traces.
Server PR
Coming soon but I've already validated this change locally.