fix(tcfeed): one unreadable repository must not end the batch - #126
Merged
Conversation
A run of sixteen stopped after three and reported nothing about the thirteen it never reached. haproxy/haproxy has pull requests turned off — it takes patches on a mailing list — so GitHub answers 404 for its pulls endpoint while the repository itself reads normally, and nothing earlier caught it. The "asked once" lookup was the only gh call in prTarget without a guard, so it threw, went past the loop's try around openPr, and ended the run. Two changes, because the second is the one that matters: - the pulls lookup treats 404 as a repository that does not accept pull requests, which is a skip reason and a true one. - the loop wraps prTarget as well as openPr. Every known failure now returns a reason rather than throwing, but prTarget makes a dozen API calls against repositories nobody here controls, and the failure mode when one of them surprises it is losing the rest of the batch silently. One repository is allowed to be unreadable. A run is not allowed to end because of it. Verified: haproxy alone skips with the reason, and haproxy followed by another repository no longer stops before reaching it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan67 finding(s) HIGH/CRITICAL: 11 | MEDIUM: 55 | LOW: 1
…and 17 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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.
A live run of 16 repositories stopped after 3 and said nothing about the 13 it never reached.
Why
haproxy/haproxyhas pull requests turned off — it takes patches on a mailing list. GitHub answers 404 for the pulls endpoint while the repository itself reads normally, sogh repo viewsucceeds and nothing earlier catches it:The "asked once" lookup was the only
ghcall inprTargetwithout a guard. It threw, sailed past the loop'stryaroundopenPr— which only ever wrappedopenPr— and ended the run.Two changes, and the second is the one that matters
does not accept pull requests. That is true, useful, and worth printing.prTargetas well asopenPr. Every known failure now returns a reason rather than throwing, butprTargetmakes a dozen API calls against repositories nobody here controls, and the failure mode when one of them surprises it is losing the rest of the batch silently. One repository is allowed to be unreadable; a run is not allowed to end because of it.Verified
tsc --strict --noEmitclean.Skips with the reason:
And — the actual bug — no longer stops before reaching the next repository:
🤖 Generated with Claude Code