Truncation throws away stacktrace when request is too large

[tristil]

Looking at this code: https://github.com/rollbar/rollbar-gem/blob/a294430137758455d0a4ec0d45f08cb5aa50d5d6/lib/rollbar/truncation.rb#L20

Because of the order of operations in the .truncate method the Rollbar gem will choose a short backtrace using MinBodyStrategy, then if the payload is still too large it will throw away the request using RemoveRequestStrategy. But in the case of a very large request the old backtrace wouldn't necessarily have been too big on its own. It's also not clear if the payload is supposed to be mutated between strategies. It seems like there are a few ways to go with this algorithm:

1. Don't mutate the payload between strategies. Or maybe first try each strategy in a non-mutating way and then use a cumulative/mutating approach if that fails.
2. Put RemoveRequestStrategy before MinBodyStrategy
3. Put RemoveRequestStrategy before MinBodyStrategy and make RemoveRequestStrategy truncate individual keys in the request parameters to see if it will fit.
4. Some sort of approach where all permutations of different strategies are compared for the one that gets closest to the limit.

[waltjones]

I would be in favor of allowing custom ordering (and removal) of strategies via the config, as well as allowing custom strategies.

Another thing that may help in your case, or for others. In practice, Rails backtraces are one of the biggest causes of large payloads. Recent support for Backtrace Cleaner can help with that. (Discussed here. https://docs.rollbar.com/docs/ruby#enabling-local-variables-in-stack-traces) It is smarter than the current backtrace strategy in the truncation code, and can be customized.