feat: add retry logic for Redis rate limiter#5939
feat: add retry logic for Redis rate limiter#5939hiSandog wants to merge 1 commit intoFlowiseAI:mainfrom
Conversation
Add exponential backoff retry mechanism when adding rate limiters with Redis store. Falls back to in-memory rate limiter if Redis is unavailable after max retries.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the resilience of the application's rate limiting system. By introducing retry logic with exponential backoff for Redis connections and providing a graceful fallback to an in-memory store, it ensures that rate limiting functionality remains operational even when facing temporary Redis outages or connection problems, thereby improving overall system stability. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a retry mechanism for the Redis rate limiter with a fallback to an in-memory store. However, the retry logic is flawed, as it ineffectively handles Redis connection issues during initialization. Additionally, a critical security vulnerability exists: the rate limiter messages, both primary and fallback, are susceptible to Stored Cross-Site Scripting (XSS) due to direct use of unsanitized user-controlled configuration.
| max: limit, | ||
| standardHeaders: true, | ||
| legacyHeaders: false, | ||
| message, |
There was a problem hiding this comment.
The message parameter, originating from chatFlow.apiConfig, is directly passed to the rateLimit middleware. This is susceptible to Stored Cross-Site Scripting (XSS) if it contains unsanitized HTML or JavaScript, as express-rate-limit sends this string as the response body. This is particularly risky if chatflows are shared or embedded in public websites.
| rateLimit({ | ||
| windowMs: duration * 1000, | ||
| max: limit, | ||
| message: `${message} (fallback mode - Redis unavailable)` |
There was a problem hiding this comment.
The same Stored XSS vulnerability exists in the fallback rate limiter message. The untrusted message is concatenated with a suffix and used as the response body for the in-memory rate limiter.
| while (retryCount < maxRetries) { | ||
| try { | ||
| this.rateLimiters.set( | ||
| id, | ||
| rateLimit({ | ||
| windowMs: duration * 1000, | ||
| max: limit, | ||
| standardHeaders: true, | ||
| legacyHeaders: false, | ||
| message, | ||
| store: new RedisStore({ | ||
| prefix: `rl:${id}`, | ||
| // @ts-expect-error - Known issue: the `call` function is not present in @types/ioredis | ||
| sendCommand: (...args: string[]) => this.redisClient.call(...args) | ||
| }) | ||
| }) | ||
| ) | ||
| break // Success, exit retry loop | ||
| } catch (error) { | ||
| lastError = error as Error | ||
| retryCount++ | ||
| if (retryCount < maxRetries) { | ||
| // Wait before retry (exponential backoff) | ||
| await new Promise(resolve => setTimeout(resolve, Math.pow(2, retryCount) * 100)) | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
The retry logic implemented here is ineffective for detecting Redis connection issues. The rateLimit() function and the RedisStore constructor are synchronous and do not perform network operations during initialization. Connection errors will only occur when the middleware is actually executed during an incoming request. Consequently, the try-catch block will not catch connection failures at this stage, and the fallback to the in-memory rate limiter will never be triggered during initialization, even if Redis is unavailable.
1 participant
Add exponential backoff retry mechanism when adding rate limiters with Redis store. Falls back to in-memory rate limiter if Redis is unavailable after max retries.