temporalio / temporalio/features

Research/solve truncating failure stack traces SDK-side so they don't get truncated server side

Open
#597 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
32
Forks
28
Avg merge
1d 9h
Merged PRs (30d)
7

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

First consult the server implementation to determine its default truncation limit for encoded failures and choose a smaller stack-trace limit. Then review each SDK's failure converter options and define the default and override behavior, including middle-frame omission; completion requires covering the listed SDKs and validating compatibility behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, java, php, python, ruby, typescript
Domain
distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.