Publish the download count instead of rendering it live, and name the traffic 403 - #138
Merged
Merged
Conversation
…thing else The first real run failed with `curl: (22) The requested URL returned error: 403`, which says the token cannot read traffic and nothing about why. The two failures that actually happen here are a token without `Administration: Read-only` and a fine-grained token the org has not approved, and both are 403. The status is now read explicitly. A 403 or 404 warns with what to grant and exits 0, the same trade the missing-secret branch already makes: neither is something the workflow can fix, and a nightly red run teaches us to ignore red runs. Any other non-200 is still an error, and the body is printed with it.
|
Warning Review limit reachedNext included review available in 5 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
… 403 Two fixes to the same workflow, both found by running it. **Downloads.** `img.shields.io/pypi/dm` renders the count live, which means shields asks pypistats on behalf of every project it serves; the badge came back `rate limited by upstream service` the day it shipped. pypistats answers a single caller instantly, so the fix is to stop being one of shields' many callers and become one of pypistats' rare ones: one request a day from here, published as `downloads-badge.json` on the badges branch like the other three. No history file, unlike clones -- pypistats keeps the series and answers for any day, so what this publishes is a reading rather than an accumulation and there is nothing for a stored file to make more correct. The two sources are independent: either can fail without taking the other's badge down, the publish step writes whichever documents were read, and the retry rebuilds each from the untracked download it already has. Exercised on a real remote: all three source combinations commit exactly their own files, and against a competing publisher holding a stale downloads badge and an extra clone day, the retry lands this run's reading and both days. **The 403.** The first real run failed with `curl: (22) The requested URL returned error: 403`, which says the token cannot read traffic and nothing about why. The status is now read explicitly; a 403 or 404 warns with what to grant and exits 0, the same trade the missing-secret branch makes. Any other non-200 is still an error, with the body. `pypi/dm/ctrlrun` is pinned as an absence in the README test: the live form is the obvious thing to reach for again.
arpanghoshal
changed the title
arpanghoshal
enabled auto-merge (squash)
September 11, 2026 16:01
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Downloads: rate limited within a day
img.shields.io/pypi/dmrenders the count live, so shields asks pypistats on behalf of every project it serves. The badge returnedrate limited by upstream servicethe day it shipped. pypistats' own API answers a single caller instantly:So
traffic.ymlnow asks once a day and publishesdownloads-badge.jsonto thebadgesbranch, and the badge reads that document instead of a third party's cache. There is no history file, unlike clones: pypistats keeps the series and answers for any day, so this is a reading rather than an accumulation and a stored file would make it no more correct.The two sources are independent. Either can fail without taking the other's badge down, the publish step writes whichever documents were read, and the retry rebuilds each from the untracked download it already has.
Exercised against a real remote rather than reasoned about:
clones: 30; downloads: 3,450/monthclones: 30downloads: 3,450/monthAnd against a competing publisher holding a stale downloads badge plus an extra clone day, the retry lands this run's reading (
3,450/month, not the stale1/month) and both clone days (99 + 45 = 144).The 403
The first real run failed with
curl: (22) The requested URL returned error: 403, which says the token cannot read traffic and nothing about why. The status is now read explicitly; 403 and 404 warn with exactly what to grant and exit 0, the same trade the missing-secret branch makes. Any other non-200 is still an error, with the body printed.Regression pin
pypi/dm/ctrlrunis now asserted absent from the README, because the live form is the obvious thing to reach for again.🤖 Generated with Claude Code