[Backend] Add Inactivity Metadata Tracking

[Yashaswini-K-P]

Description

Before we can optimize our synchronization workflow, the system needs a way to identify stale user profiles. Currently, we have no concept of when a user was last active.

This issue lays the foundational groundwork by introducing two tracking metadata fields—lastActive (an ISO timestamp) and status ("active" | "inactive")—directly into the overall.json data file.

---

Execution Plan:

I will implement this tracking logic directly inside scripts/sync-leaderboard.js using the following workflow:

1. Read and State Preservation

• Load the existing overall.json at the start of the script execution.
• Ensure that for every user processed, their existing lastActive and status values are read into memory so they aren't accidentally wiped or overwritten during the sync loop.

2. Live Activity Detection Loop

For every user fetched during the sync cycle, the script will compare their newly fetched totalSolved count against the totalSolved count currently stored in overall.json:

• Scenario A: Total Solved Count Has Increased 📈

  • This confirms recent activity.
  • Update lastActive to the current timestamp (new Date().toISOString()).
  • Set status to "active".

• Scenario B: Total Solved Count is Unchanged ⏳

  • Calculate the delta time: Current Time - user.lastActive.
  • If a user doesn't have a lastActive timestamp yet, default it to the current time to establish a baseline.
  • If the calculated time elapsed exceeds 90 days, change their status to "inactive".
  • Otherwise, leave their status as "active".

3. File Write Back

• Safely stringify and write the updated user array back to overall.json, ensuring all previous data structures remain completely intact alongside the new metadata fields.

Pls Assign this to me , I would love to work on it .

[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.

[jagdish-15]

This seems like a fair direction overall, though I think it would probably make more sense to keep this separate from the existing 5-minute sync workflow.

Since inactivity changes very slowly compared to leaderboard data, constantly recalculating and storing activity metadata during every sync cycle may be unnecessary overhead.

A cleaner approach might be:

• creating a separate daily workflow/script for inactivity analysis (create a workflow similar to the existing one, which runs in the current repo, but the changes are executed in the data repo),
• using the existing submissionCalendar data already returned by the LeetCode API (instead of relying on constant 90-day recalculations),
• determining inactivity based on the latest submission timestamp present there (the last one in the list),
• and generating something like an inactive-users.json file instead of mutating overall.json with persistent status fields.

That would also avoid keeping duplicated derived state like "active" / "inactive" inside the leaderboard datasets themselves.

Something like this for the generated file structure could work well:

{
  "generatedAt": "2026-06-14T00:00:00Z",
  "thresholdDays": 90,
  "inactiveUsers": [
    "user1",
    "user2",
    "user3"
  ],
  "neverActiveUsers": [
    "user4",
    "user5"
  ]
}

neverActiveUsers can be used for users with no submission history at all (basically the 0-score users currently present in the overall leaderboard dataset).

[jagdish-15]

One thought, since we can already identify the never-active users fairly easily, cuz they’re basically the 0-score users in the overall leaderboard dataset (#178 already uses that to indentify them)

So for this issue specifically, I think it would be cleaner to simply ignore users with no submission history instead of storing them separately in neverActiveUsers