Closed rsenden closed 1 year ago
For reference, this should probably be implemented as an Interceptor
(unless Unirest has better ways for handling this in a generic way), in a similar way as UnirestUnexpectedHttpResponseConfigurer
. We should either add an additional interceptor for handling rate limits (in which case interceptor order may matter), or have a single interceptor that handles both rate limits and other unexpected responses, thereby replacing UnirestUnexpectedHttpResponseConfigurer
.
For FoD, the 'rate limit handler configurer' should be invoked from here: https://github.com/fortify/fcli/blob/64d81e2764a1ddd4c9c87a7b95cb6c45589b86df/fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/_common/output/mixin/FoDProductHelperBasicMixin.java#L35 For consistency, maybe it should also be configured from here: https://github.com/fortify/fcli/blob/64d81e2764a1ddd4c9c87a7b95cb6c45589b86df/fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/_common/session/helper/oauth/FoDOAuthHelper.java#L54
Seems more complicated than expected: https://github.com/Kong/unirest-java/issues/491
For reference, this issue can be easily reproduced by running multiple update commands shortly after another, for example fcli fod app update <id> -n <name>
, as FoD imposes a rate limit of 1 request every 30 seconds on this operation.
Especially with update operations, FoD rate limits are quite low, so it's likely that automation scripts that utilize fcli to perform updates run into rate limits. Fcli will currently likely fail when rate limits are being hit; we should handle this gracefully, i.e. retry the operation when the rate limit has been reset.
Fcli currently fails with an error like the following if rate limits are hit:
Some other Fortify integrations already gracefully handle rate limits, so we can potentially re-use some of the code. See for example: