Problem with Redis keys on distributed systems

[OscarRomaFever]

In some large, distributed projects that run across different machines, the order in which FastAPI endpoint routes are loaded can vary. This can cause the keys generated for each pod to have different values, leading to separate caches per machine. This is due to this code.

Would it be possible to change the way keys are generated, or at least allow users to change how they are generated?

I attach here a PR proposal for fastapi-limiter. Any other approach could be useful for us, like allowing the user to pass full generated key, instead of just rate_key.
Other option, that will not change the code of the project, is to create a method create_key for this line. This way, any user could be able to monkey_patch this method.

Thank you so much for forking the Fastapi-limiter repository and trying to keep it active. This is very helpful for many of us☺️.

[rayakame]

Hi! First of all thank you for using my fork of fastapi-limiter, I will take a deeper look at the issue.

I'm sorry that it took so long for you to get a response, I was very busy with some other things.

From the first look at the PR proposal, that wouldn't work because that would break the functionality of having multiple RateLimiter(s) as shown here.

I already have an idea how I could fix the issue that you are encountering with distributed servers, but the idea of allowing the user to change the way that keys are generated sounds very interesting, so I will try and see if I can come up with something that would fulfill this goal.

[OscarRomaFever]

Thank you so much for your response :).
I hadn't realized the change could break the use of multiple rate limiters. Good catch.
I'll be keeping an eye on the project's progress. Great work!