Skip to content

chore(data): refresh contest training data - #162

Closed
github-actions[bot] wants to merge 1 commit into
mainfrom
chore/refresh-training-data
Closed

github-actions[bot] wants to merge 1 commit into
mainfrom
chore/refresh-training-data

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Automated weekly refresh of data/data.json via
scripts/update_data.py.

Retraining is a separate, manual step: see CONTRIBUTING.md. Merging
this only updates the training inputs, not the served model.

@sonarqubecloud

sonarqubecloud Bot commented Sep 2, 2026

Copy link
Copy Markdown

Sagargupta16 added a commit that referenced this pull request Sep 3, 2026
… set (#163)

* fix(data): stop the weekly refresh from silently halving the training set

PR #162 was the refresh job's first successful run since 2026-08-17, and it
proposed replacing data/data.json with 123,513 records against the 244,950
already committed. Every check passed. Three independent causes:

1. update_data.py prompted for a user count, so under CI input() raised
   EOFError and it fell back to min(5000, len(usernames)). The committed
   dataset came from 6,830 contributing users, so the cron could never
   reproduce it: both refs average 35.9 records per user, meaning even a
   flawless 5,000-user run lands about 27% short. --users now defaults to
   8,000.

2. A throttled fetch was indistinguishable from an account with no contests,
   because any non-200 returned []. 1,560 of 5,000 users "failed" that way.
   Retryable statuses (429, 5xx) and network errors now retry with exponential
   backoff honouring Retry-After, and a failed fetch returns None so the run
   summary counts failures apart from genuinely empty accounts.

3. Nothing compared the new dataset against the old before overwriting. A run
   retaining less than --min-retention (default 95%) now aborts with a non-zero
   exit, which fails the workflow instead of opening a PR that deletes data.
   --force overrides it.

The user cap is bounded by GitHub's 100 MB per-file hard limit, since
data/data.json is committed. At ~8.3 KB per contributing user, all 43,158
usernames would yield roughly a 307 MB file that could never be pushed, so
"just fetch everyone" is not available. 8,000 lands near 57 MB. The script
logs the written size and warns past 90 MB.

Also writes through a temp file plus os.replace so an interrupted run cannot
truncate the dataset, and drops a time.sleep(0.05) in the result loop that
throttled nothing (futures are all submitted up front) while adding 250s of
pure latency per 5,000 users.

Verified with 25 offline checks against a fake session (429 exhaustion returns
None not [], 404 is not retried, Retry-After honoured and capped, tally
separates failed from empty) and 18 end-to-end checks driving main() against a
throwaway repo layout: the guard blocks a shrinking run and leaves data.json
byte-identical, --force overrides, growth is allowed, and an all-failed run
never writes an empty file. Repo ruff clean, 59/59 pytest passing.

* fix(deps): relock uv.lock for the 2.3.2 version bump

`uv sync --locked` fails when pyproject.toml's version differs from the one
recorded in uv.lock, which broke the python CI job. Only the project version
entry changed; no dependency was re-resolved.
@Sagargupta16

Copy link
Copy Markdown
Owner

Closing rather than merging: this run would have deleted 121,437 training records (49.6% of the dataset).

Counted directly on both refs:

Records Contributing users Records/user
main 244,950 6,830 35.9
this PR 123,513 3,440 35.9

Records-per-user is identical, so per-user data quality was fine. The whole shortfall was fewer users getting through: Failed/No data: 1560 out of 5,000, which the script could not distinguish from accounts with no contest history.

Fixed in #163, now on main:

  • a retention floor (default 95%) aborts the run non-zero instead of overwriting data/data.json, so a throttled fetch fails the workflow rather than opening a PR like this one
  • 429/5xx and network errors retry with backoff honouring Retry-After; a failed fetch is now counted separately from an empty account
  • --users replaces the interactive prompt that EOFError-ed into a 5,000-user cap under CI, and defaults to 8,000 (the committed dataset needs 6,830 successful users)

The next scheduled run on 2026-09-08 regenerates this PR against the same branch, with the guards in place.

@Sagargupta16
Sagargupta16 deleted the chore/refresh-training-data branch September 3, 2026 08:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant