chore(refactor): flatten duplicated contribution loops in get_user_activities#278
Merged
Merged
Conversation
…tivities
get_user_activities built its commits, pull requests, issues and reviews lists
with four near-identical double loops, each manually descending into
contributions.nodes. The outer iteration and org/repo filtering already lived
in the _filtered_contributions generator, so this moves the inner descent into
it too: the generator now yields individual contribution nodes and each of the
four blocks becomes a single flat loop, dropping a nesting level and the
repeated .get("contributions", {}).get("nodes", []).
No behaviour change. The old inner break stopped appending once max_results was
reached while the outer loop kept spinning as a no-op; the flat loop stops at
the same point. Verified byte-identical output by replaying a cached real
GraphQL response through the extraction before and after (with max_results
capping every list).
saidsef
added
python
Up to standards ✅🟢 Issues
|
| Category | Results |
|---|---|
| Documentation | 4 minor |
🟢 Metrics -4 complexity
Metric Results Complexity -4
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
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.
What
get_user_activitiesbuilt its commits, pull requests, issues and reviews lists with four near-identical double loops, each manually descending intocontributions.nodesbefore appending. The outer iteration and org/repo filtering already lived in the_filtered_contributionsgenerator, so this moves the inner descent into it as well. The generator now yields individual contribution nodes, and each of the four blocks collapses to a single flat loop - one less level of nesting and no repeated.get("contributions", {}).get("nodes", []).Why
Removes the last piece of structural duplication in the method and makes the four blocks read uniformly. The per-type result dicts - the only thing that genuinely differs between them - are left exactly as they were.
No behaviour change
The old inner
breakstopped appending oncemax_resultswas hit while the outer loop kept spinning as a no-op; the flat loop stops at the same point (and iterates a little less). Because that field extraction has no unit test, I proved equivalence directly: cached a real GraphQL response, then ran the extraction before and after the change - the JSON output is byte-identical, withmax_resultsactively capping every list so the break path is exercised.Testing
uv run pytest -q- 56 passedruff check src/andpyright- cleanget_user_activitiesover MCPFollow-up to the de-duplication in #277; touches different lines of the same method, so the two do not conflict.