ci: prevent rate limiting in release-commenter action

[denolfe]

Overview

Fixes GitHub secondary rate limit errors in the release-commenter action when processing releases with many PRs.

Key Changes

• Sequential processing for comment creation

  • Replaced parallel Promise.all with sequential processing and 1s delay between each PR
  • Added progress logging: Processing issue/PR 1/20: #123

• Updated tests for async timing

  • Added Jest fake timers to handle sequential delays in tests

Design Decisions

GitHub's secondary rate limits restrict content creation to 80 requests/minute and penalize burst patterns regardless of total volume. The previous implementation fired all comment/label requests in parallel, triggering the "content creation" throttle even when under primary rate limits.

Sequential processing with a 1s delay trades speed for reliability. For a release with 20 PRs, processing takes ~20s instead of ~2s—an acceptable tradeoff given releases are infrequent and reliability matters more than speed.

GraphQL queries (read operations) remain parallel since they're less likely to trigger secondary limits.

Overall Flow

sequenceDiagram
    participant Action
    participant GitHub API

    Action->>GitHub API: Get releases (parallel)
    Action->>GitHub API: Compare commits (parallel)
    Action->>GitHub API: GraphQL queries for PRs (parallel)
    
    loop For each linked issue/PR
        Action->>GitHub API: Get issue state
        Action->>GitHub API: Create comment (+ unlock/lock if needed)
        Action->>GitHub API: Add labels (if configured)
        Note over Action: Wait 1s before next
    end

Loading

References / Links

• GitHub REST API Rate Limits
• Failed run example

[github-actions]

🚀 This is included in version v3.73.0