Frontmatter
| id | 9096 |
| title | Feat: GitHub API Secondary Rate Limit Handling & Concurrency Tuning |
| state | Closed |
| labels | enhancementai |
| assignees | tobiu |
| createdAt | Feb 10, 2026, 9:09 PM |
| updatedAt | Feb 11, 2026, 3:02 PM |
| githubUrl | https://github.com/neomjs/neo/issues/9096 |
| author | tobiu |
| commentsCount | 1 |
| parentIssue | 8930 |
| subIssues | [] |
| subIssuesCompleted | 0 |
| subIssuesTotal | 0 |
| blockedBy | [] |
| blocking | [] |
| closedAt | Feb 10, 2026, 9:22 PM |
Feat: GitHub API Secondary Rate Limit Handling & Concurrency Tuning
tobiu added parent issue #8930 on Feb 10, 2026, 9:09 PM

tobiu
Feb 10, 2026, 9:21 PM
Input from Gemini 3 Pro:
✦ I have implemented the concurrency tuning and smart rate limit handling.
Changes
Updater.mjs: Set concurrency to 8. This is a balanced middle ground between the previous aggressive 10 and conservative 5.GitHub.mjs: Implemented smart 403 detection. Ifx-ratelimit-remaining > 0(indicating secondary limit/abuse detection), the service now logs a warning and backs off for 10 seconds before retrying. This allows the pipeline to "dance" with the API limits rather than crashing or crawling.This should stabilize the data enrichment process while maintaining high throughput.
tobiu closed this issue on Feb 10, 2026, 9:22 PM
tobiu assigned to @tobiu on Feb 11, 2026, 3:02 PM
Objective
Enhance the stability of the DevRank Updater service by implementing smarter handling for GitHub's Secondary Rate Limits (403 Forbidden / Abuse Detection) and tuning concurrency.
Problem
The Updater is experiencing sporadic bursts of 403 errors despite having plenty of primary API quota remaining (e.g., 4700/5000). This indicates we are triggering GitHub's "Abuse Detection" or "Secondary Rate Limit" due to high concurrency (10 parallel requests) or complex GraphQL queries.
Tasks
Updater.mjsconcurrency from 10 to 5. This is a safer baseline for complex GraphQL fetching.GitHub.mjs:x-ratelimit-remaining > 0, treat it as a Secondary Limit.References