Retry failed token price updates

[Gudahtt]

Explanation

The token-prices-service will now retry token price updates if they fail. The retry strategy is designed to let the API recover if it is experiencing high traffic volumes.

The service now requires state in order to hold onto the retry policy. It has been converted to a class for that reason. This required no changes to the abstract price service type or to the TokenRatesController.

References

Closes #2084

Changelog

@metamask/assets-controllers

• Changed: The CodefiTokenPricesServiceV2 will retry if the token price update fails
  • We retry each request up to 3 times using a randomized exponential backoff strategy
  • If the token price update still fails 5 times consecutively (including the 3 retries each attempt, so 15 consecutive failures total), we stop trying for 30 minutes before we try again.
  • The service has been converted from a collection of functions to a class. The newly added constructor has these options:
    • tokenPriceRetryAttempts - Number of retry attempts for each token rate update.
    • tokenPriceMaximumConsecutiveFailures - The maximum number of consecutive failures allowed before breaking the circuit and pausing further updates.
    • tokenPriceCircuitBreakDuration - The amount of time to wait when the circuit breaks from too many consecutive failures.

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

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
cockatiel	3.1.1	filesystem, shell	+0	693 kB	connor.peet

[socket-security]

👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

Ignoring: [email protected]

Next steps

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore [email protected] bar@* or ignore all packages with @SocketSecurity ignore-all

[Gudahtt]

@SocketSecurity ignore [email protected]

This package shouldn't have shell access, but it's only being used in a test file. I have made an issue requesting that they be removed here: connor4312/cockatiel#84

[mcmire]

Nice job with the tests — I appreciate the comments. I'm surprised that we don't have to account for the jitter in ExponentialBackoff when we mock timers, but I'm not complaining. I'm also curious whether it makes sense to move the retry functionality out of this file in the future so that an arbitrary service object can be customized with retry functionality, but we can cross that bridge when we get there.

Two comments, but both are non-blocking.

[Gudahtt]

I'm surprised that we don't have to account for the jitter in ExponentialBackoff when we mock timers, but I'm not complaining

That's why I used the max delay - to not have to worry about the random jitter affecting the timing. Even with the exponential backoff and random jitter, it should always be delayed by no greater than the max delay.

Of course that 30 second wait is way way longer than it typically waits between retries, but in an environment with fake timers that doesn't really matter.

[mcmire]

Looks good!