[tomellm]

This is our initial idea on how to implement some kind of rate limiting in the system. Please consider that this is still in progress and in no way done so there definitely are a few dumb mistakes in here.

Overview

The general idea is the following. On every request we can know how our rate-limiting stats. This allows us to adjust requests so that we don't hit the rate-limit. To adjust the number of requests being made we decided to have a kind of status based system. The github-adapter tracks the rate-limit stats and updates this status accordingly. With this status we can then decide for every adapter individually if makes sense to keep fetching new data or to wait it out until the limit improves.

Implementation

To be able to decide when to make a request and when not to we though changing the way scheduling works was needed.

Before

the exporters defined a schedule on which the the Github Api was hit. The caching layer existed because some exporters needed the same Api paths leading to redundand requests.

Now

the exporters have been decoupled from the Github Api. The exporters run periodically very 30s but they practically always hit the caches. These caches are now evicted on the schedule that exporters were running before. Functionally this is the same as before, but compared to before this allows us to decide not to evict the cache if nessesary, which is what we are doing.

Every Adapter implementation then looks at the current Ratelimit status, which is one of the following:

github-metrics/domain/src/main/java/be/xplore/githubmetrics/domain/apistate/ApiRateLimitStatus.java

Lines 5 to 8 in 99ddcf1

	public enum ApiRateLimitStatus {
	CRITICAL, WARNING, CONCERNING, GOOD, OK;

and decides whether to cache evict or not.

Changing the status

To look at the headers of every response gotten I decided to use a interceptor on the RestClient. This interceptor looks at the ratio of requests made to time passed and compares it to a "ideal" ratio. This ideal ratio is simply calculated from the ratelimit state. When comparing the "actual" and the "ideal" ratio we can then set the status. The "ideal" ratio times one of these multiplies should be less or equal to the "actual" to result in the following statuses.

ideal * 1.2 >= actual -> CRITICAL
ideal * 0.9 >= actual -> WARNING
ideal * 0.7 >= actual -> CONCERNING
ideal * 0.5 >= actual -> GOOD
else -> OK

*Consider that even tho the status may jump from OK to CRITICAL it can only go down one step at a time.

[henrybley]

mostly looking good just the few comments

[henrybley]

this should be .env configurable

[tomellm]

done

[henrybley]

I think all these should be .env configurable

[tomellm]

done

[henrybley]

should this be committed? this was for your testing I assume?

[tomellm]

done

[henrybley]

looks good to me

[sonarqubecloud]

Quality Gate failed

Failed conditions
66.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud