Description
In sync-leaderboard.js, when performing the daily stats sync, the script makes an external request to fetch live LeetCode stats for each active user. If the wrapper API fails (due to a rate limit HTTP 429, timeout, or DNS failure), the script skips that user:
// scripts/sync-leaderboard.js
const data = await fetchData(baseUrl + user.id);
if (!data) {
console.log(`${user.name}: skipped (API error)`);
return;
}Because the execution return is premature, the user is completely omitted from the newly written overall.json. Consequently, the user disappears from the leaderboard until the next successful sync runs. This also corrupts delta calculations (e.g., treating them as [new] users when they reappear).
Expected Behavior
If fetching live data fails for an active user, the script should fall back to recycling their last known score and data structure from the cached overall map (historyMap), rather than dropping them.
Proposed Solution
Update sync-leaderboard.js to look up the user's previous data from historyMap as a fallback inside the fetchData failure block.
Description
In
sync-leaderboard.js, when performing the daily stats sync, the script makes an external request to fetch live LeetCode stats for each active user. If the wrapper API fails (due to a rate limit HTTP 429, timeout, or DNS failure), the script skips that user:Because the execution return is premature, the user is completely omitted from the newly written overall.json. Consequently, the user disappears from the leaderboard until the next successful sync runs. This also corrupts delta calculations (e.g., treating them as [new] users when they reappear).
Expected Behavior
If fetching live data fails for an active user, the script should fall back to recycling their last known score and data structure from the cached overall map (historyMap), rather than dropping them.
Proposed Solution
Update sync-leaderboard.js to look up the user's previous data from historyMap as a fallback inside the fetchData failure block.