check entire Throwable in RetryMapping::matchesThrowable

[alexeyqu-fb]

This becomes important when the original exception (e.g. rate limit exceeded) is shadowed with a wrapping exception somewhere, so the toString doesn't contain the important information anymore.

Using ExceptionUtils.getStackTrace from lang3.exception is one of the ways to look into the stack trace -- however, I am open to suggestions.

cc @xokker

[jzacsh]

does leaving the previous loop seem like a micro-optimization? should we just delete it for now and add something like this (or something else) in later, if we do performance testing and find this area problematic?

EDIT: I see the loop before is actually probably very different (first loop vs. second loop). so maybe just add a comment block atop both loops explaining (eg: // try to match on throwable's faster-to-compute string and // see if maybe the fuller stacktrace reveals any matches)?

[jzacsh]

I'm not very familiar with this class, but maybe it'd increase confidence if we started adding unit test coverage? Maybe not to this file, but to its one and only user (as far as I can tell): RetryStartegyLibrary itself? eg: maybe then it'd be easy (for future us) to see this PR was just adding a new test case?

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ xokker
❌ alexeyqu-fb
_{You have signed the CLA already but the status is still pending? Let us recheck it.}