You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today if a failure is too large, the server truncates. But the server can't truncate a stack trace for an "encoded" failure (i.e. one that is in the encoded_attributes), so that entire set of payloads is dropped which means the entire message and stack trace is gone, not just partial. So we need to do this SDK side.
Need to truncate the stack trace to a reasonably small size by default, ideally cutting out the middle frames only replacing them with "...X frames omitted..." or something. And this should be overridable in the failure converter options. First task is to find out what that number is, which likely requires consulting with the server to see what their default truncation size is and stay a bit under that (since theirs may be whole-proto size and ours is just stack trace).
Per-SDK Tickets
Go -
Java -
Core -
TypeScript -
Python -
.NET -
Ruby -
PHP -
Temporal CLI - N/A
The text was updated successfully, but these errors were encountered:
cretz
changed the title
Research truncating failure stack traces SDK-side so they don't get truncated server side
Research/solve truncating failure stack traces SDK-side so they don't get truncated server side
Feb 12, 2025
Describe the solution you'd like
Today if a failure is too large, the server truncates. But the server can't truncate a stack trace for an "encoded" failure (i.e. one that is in the
encoded_attributes
), so that entire set of payloads is dropped which means the entire message and stack trace is gone, not just partial. So we need to do this SDK side.Need to truncate the stack trace to a reasonably small size by default, ideally cutting out the middle frames only replacing them with "...X frames omitted..." or something. And this should be overridable in the failure converter options. First task is to find out what that number is, which likely requires consulting with the server to see what their default truncation size is and stay a bit under that (since theirs may be whole-proto size and ours is just stack trace).
Per-SDK Tickets
The text was updated successfully, but these errors were encountered: