Complete createServicePolicy

[mcmire]

Explanation

This commit is a continuation of a previous commit which added a utility function for use in service classes which ensures that they follow the circuit breaker and retry patterns.

This commit completes the function by adding:

• retryFilterPolicy, which allows for retrying certain errors and not handling others.
• maxRetries, which allows for giving up early before the max consecutive failures is reached. Note that because this can combine with maxConsecutiveFailures, it adds a bunch of other code paths and so this requires adding a lot of new tests.

References

Progresses #4994.

Changelog

(Updated in PR)

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've highlighted breaking changes using the "BREAKING" category above as appropriate
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

[mcmire]

So... the amount of changes here are still very large, and it really screws up the diff. I probably could have pre-organized these tests up front the way they are presented now to make the diff easier to read, but regardless, there are a large number of tests being added.

I will repeat the same instructions I gave before: it's probably best to run this command to view the test names from a high level:

yarn workspace @metamask/controller-utils run jest packages/controller-utils/src/create-service-policy.test.ts --no-coverage

Or, go into VSCode, run "Fold All", and then progressively unfold the describe blocks.

There you should be able to see some patterns. First, I've divided the tests into three major scenarios:

1. wrapping a service that succeeds on the first try
2. wrapping a service that always fails
3. wrapping a service that fails continuously and then succeeds on the final try

The 1st scenario is pretty simple; all we need to really test is that onBreak is never called, and onDegraded is sometimes called.

The 2nd scenario adds complexity, because since both maxRetries and maxConsecutiveFailures are optional, there are four code paths we have to test, and then inside that there are more code paths depending on whether the number of retries is greater than, less than, or equal to the number of consecutive failures. All of that affects whether/when onBreak or onDegraded are called.

Finally, the 3rd scenario is also important because that is where we can test that the service gets re-evaluated if it fails enough times that the circuitBreakDuration elapses. (We also test a bunch of stuff we are already testing in the 2nd scenario. Despite the duplication I thought these tests were still important so we know what happens.)

[mcmire]

Should we call this retries instead of maxRetries?

I guess a better question is, how would you expect to use this function?

const policy = createServicePolicy({ maxRetries: 3 });

vs:

const policy = createServicePolicy({ retries: 3 });