Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iterate more aggressive string truncation if needed #865

Merged
merged 3 commits into from
May 8, 2019

Conversation

waltjones
Copy link
Contributor

@waltjones waltjones commented May 7, 2019

Fixes #864

Current truncation strategy:

  1. Limit the number if stack frames
  2. Truncate all strings to 1024, then 512, then 256 bytes.
  3. Limit to only the most current stack frame.

This PR extends string truncation to 128 and 64 bytes, and adds the size of all truncation attempts to the error message when truncation fails.

It has been suggested that parts of the payload can be removed entirely as a truncation step. This may be appropriate, but we don't know yet which part is causing the issue or the nature of why it's oversized.

@waltjones waltjones force-pushed the wj-string-truncation branch from a4b5480 to ed3112c Compare May 8, 2019 21:03
@waltjones waltjones changed the title WIP: Iterate more aggressive string truncation if needed Iterate more aggressive string truncation if needed May 8, 2019
@waltjones waltjones merged commit 7dd2d9a into master May 8, 2019
@waltjones waltjones deleted the wj-string-truncation branch June 27, 2023 18:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Truncation does not always produce a small-enough payload
1 participant