analyze-inactivity.js lacks retry logic and uses aggressive concurrency

[rishab11250]

Description

The analyze-inactivity.js script fetches LeetCode profile data for all registered users but is missing three safeguards that sync-leaderboard.js already implements:

1. No retry logic on API failure — if a request fails, the user is silently skipped.
2. 50-user concurrency (vs 20 in sync-leaderboard) — higher risk of rate limiting.
3. No fallback to stale data — if the API fails, the user is simply skipped and not included in the output.

Affected Code

const CONCURRENCY_LIMIT = 50;  // sync-leaderboard.js uses 20

// No retry interceptor configured (sync-leaderboard.js has one)
async function fetchData(url) {
  try {
    const res = await axios.get(url, { timeout: 15000 });
    return res.data;
  } catch (err) {
    console.error(`API failed for ${url}: ${err.message}`);
    return null;    // ← silently skips user on any failure
  }
}

Steps to Reproduce

1. Run node scripts/analyze-inactivity.js
2. If the LeetCode API rate-limits or returns errors for some users, those users are excluded from analysis
3. No retry, no fallback — silently missing from the inactive list

Expected Behavior

Should match the resiliency pattern in sync-leaderboard.js:

• Retry failed requests up to 3 times with exponential backoff.
• Use concurrency of 20 (or configurable) instead of 50.
• When all retries fail, log a warning but still include the user with a "skip" flag rather than silently omitting them.

Suggested Fix

1. Extract the retry interceptor from sync-leaderboard.js (lines 11-55) into a shared module or duplicate it in analyze-inactivity.js.
2. Reduce CONCURRENCY_LIMIT from 50 to 20.
3. On complete failure after retries, include the user with { status: "unreachable" } instead of dropping them.

Affected Files

• scripts/analyze-inactivity.js

[github-actions]

Thank you for opening an issue.

Please review our CONTRIBUTING.md guidelines before getting started.

A maintainer will review this issue shortly. If you would like to work on the issue yourself, please leave a comment requesting assignment.

Issue Assignment Policy

• The issue creator is given the first priority to work on their issue.
• If the creator declines or does not request assignment, the issue will be assigned to others in the order of requests received.
• Please do not submit PRs or begin work until you are officially assigned.

Note: This project is currently maintained by a solo maintainer, so reviews, assignments, and responses may sometimes take a little time. Thanks for your patience.

[rishab11250]

I want to work on this