Repository navigation
Conversation
Contributor
Summary by CodeRabbit
WalkthroughProject-scoped GitHub and OWASP dataloaders are added and connected to asynchronous ChangesProject-scoped data loading
Local database volume naming
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## feature/graphql-dataloaders #5240 +/- ##
============================================================
Coverage 98.82% 98.83%
============================================================
Files 547 548 +1
Lines 17306 17393 +87
Branches 2473 2481 +8
============================================================
+ Hits 17103 17190 +87
Misses 101 101
Partials 102 102
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
3 similar comments
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@backend/src/apps/github/api/internal/dataloaders/issue.py`:
- Around line 18-47: Update load_recent_issues_by_project_id and the equivalent
project-based loaders in milestone.py, pull_request.py, release.py, and
project.py to support per-key limits instead of applying keys[0][1] to every
project. Add the same database-side per-project row cap used by
load_issues_by_repository_id, using Window/RowNumber or the established
equivalent, then preserve input-key ordering and per-project results.
In `@backend/src/apps/github/api/internal/dataloaders/milestone.py`:
- Around line 20-49: Update load_recent_milestones_by_project_id to support
per-key limits instead of assuming keys[0][1] applies to every project. Add a
database-side per-project cap using the same Window-based approach as
load_recent_milestones_by_repository_id, while preserving ordering and the
returned project-key alignment.
In `@backend/src/apps/github/api/internal/dataloaders/pull_request.py`:
- Around line 14-43: The load_recent_pull_requests_by_project_id loader
incorrectly assumes one limit for the entire batch and fetches all matching
records before truncating in Python. Update this function to support each key’s
project-specific limit and apply an appropriate database-side cap while
preserving the returned results grouped in the original key order.
In `@backend/src/apps/github/api/internal/dataloaders/release.py`:
- Around line 20-53: Update load_recent_releases_by_project_id to support
per-key limits instead of assuming keys[0][1] applies to every project, and
avoid fetching all matching releases before truncation. Apply a database-side
bound or otherwise limit the query per project, while preserving the returned
ordering and per-project results.
- Around line 30-35: Update the project-level recent releases query in the
releases loader to filter out pre-releases by adding the existing
is_pre_release=False condition alongside is_draft and published_at filters. Keep
the repository__project__in filtering and other query behavior unchanged.
In `@backend/src/apps/owasp/api/internal/dataloaders/project.py`:
- Around line 44-71: Update load_health_metrics_list_by_project_id to support
per-key limits instead of applying keys[0][1] to every project; ensure each
project’s query results are capped by that project’s requested limit while
preserving chronological ordering and batching behavior.
- Around line 111-121: The load_repositories_count_by_project_id function
currently counts all related repositories, unlike the repositories list scope.
Update its Count("repositories") annotation to apply the
organization__isnull=False filter, preserving the existing batching and
zero-default behavior.
- Around line 87-108: The load_issues_count_by_project_id loader incorrectly
filters its annotation to open issues, duplicating
load_open_issues_count_by_project_id. Remove ISSUES_COUNT_FILTER from the
items_count annotation so it returns the total issue count while preserving the
existing batching and result mapping.
In `@backend/src/apps/owasp/api/internal/nodes/project.py`:
- Around line 149-152: Update the repositories_count resolver to use the same
organization-non-null filtering as repositories, ensuring the
REPOSITORIES_COUNT_BY_PROJECT_ID dataloader count matches the repositories list
length. Reuse the existing repositories filtering logic or adjust the underlying
count query keyed by REPOSITORIES_COUNT_BY_PROJECT_ID; leave behavior unchanged
for repositories with an organization.
In `@docker-compose/local/compose.yaml`:
- Line 58: Update the PostgreSQL volume configuration for the Compose service
using the `db-data` volume so existing installations backed by `db-data-5079`
retain access to their data. Either preserve the previous volume mapping or add
explicit migration guidance for renaming or backing up the old volume; if data
reset is intentional, state that clearly in the relevant Compose documentation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ac93e6fa-1445-4476-99b5-af747cfc5289
📒 Files selected for processing (16)
backend/src/apps/github/api/internal/dataloaders/__init__.pybackend/src/apps/github/api/internal/dataloaders/issue.pybackend/src/apps/github/api/internal/dataloaders/milestone.pybackend/src/apps/github/api/internal/dataloaders/pull_request.pybackend/src/apps/github/api/internal/dataloaders/release.pybackend/src/apps/github/api/internal/dataloaders/repository.pybackend/src/apps/owasp/api/internal/dataloaders/project.pybackend/src/apps/owasp/api/internal/nodes/project.pybackend/tests/unit/apps/github/api/internal/dataloaders/issue_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/milestone_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/pull_request_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/release_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/repository_test.pybackend/tests/unit/apps/owasp/api/internal/dataloaders/project_test.pybackend/tests/unit/apps/owasp/api/internal/nodes/project_test.pydocker-compose/local/compose.yaml
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 16 files
Confidence score: 5/5
- Safe to merge after the addressed issues were fixed.
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
backend/src/apps/owasp/api/internal/dataloaders/project.py (1)
3-17: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winUse each key’s requested limit in the batch loader
load_health_metrics_list_by_project_idstill useslimit = keys[0][1], so a batched request with mixed limits applies the first key’s limit to every project. Use the per-key limit when building the grouped results.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/src/apps/owasp/api/internal/dataloaders/project.py` around lines 3 - 17, Update load_health_metrics_list_by_project_id to apply each key’s requested limit when constructing grouped health-metrics results, instead of using keys[0][1] for every project. Preserve the existing grouping and ordering behavior while ensuring mixed-limit batched requests return the correct number of records per project.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@backend/src/apps/github/api/internal/dataloaders/issue.py`:
- Around line 89-99: Update load_issues_count_by_project_id to count issues only
through repositories associated with an organization, matching the scope used by
ProjectNode.repositories and repositories_count. Apply the organization filter
within the Count annotation, and change the docstring to describe the value as
the “total issues count.”
---
Outside diff comments:
In `@backend/src/apps/owasp/api/internal/dataloaders/project.py`:
- Around line 3-17: Update load_health_metrics_list_by_project_id to apply each
key’s requested limit when constructing grouped health-metrics results, instead
of using keys[0][1] for every project. Preserve the existing grouping and
ordering behavior while ensuring mixed-limit batched requests return the correct
number of records per project.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 896a9a21-5781-4e6d-8c3e-917a4323e315
📒 Files selected for processing (10)
backend/src/apps/github/api/internal/dataloaders/issue.pybackend/src/apps/github/api/internal/dataloaders/release.pybackend/src/apps/github/api/internal/dataloaders/repository.pybackend/src/apps/owasp/api/internal/dataloaders/project.pybackend/src/apps/owasp/api/internal/nodes/project.pybackend/tests/unit/apps/github/api/internal/dataloaders/issue_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/release_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/repository_test.pybackend/tests/unit/apps/owasp/api/internal/dataloaders/project_test.pybackend/tests/unit/apps/owasp/api/internal/nodes/project_test.py
💤 Files with no reviewable changes (1)
- backend/tests/unit/apps/owasp/api/internal/dataloaders/project_test.py
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 10 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 8 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
ahmedxgouda
marked this pull request as ready for review
July 19, 2026 07:28
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
backend/src/apps/github/api/internal/dataloaders/issue.py (1)
19-43: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winUniform batch limit still assumed for
load_recent_issues_by_project_id.
limit = keys[0][1](line 27) is used for every project in the batch, even though the DB-side capping viaWindow/RowNumbernow works correctly. If the batch mixes projects requested with different limits, every project gets truncated to the first key's limit. Shares root cause withmilestone.py,pull_request.py, andrelease.py— see the consolidated comment for the fix.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/src/apps/github/api/internal/dataloaders/issue.py` around lines 19 - 43, Update load_recent_issues_by_project_id to support per-project limits instead of applying keys[0][1] to the entire batch. Preserve the window-function ranking, but apply each project’s requested limit when filtering or assembling results, ensuring mixed-limit batches return the correct number of issues for every project.backend/src/apps/github/api/internal/dataloaders/milestone.py (1)
19-43: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winUniform batch limit still assumed for
load_recent_milestones_by_project_id.Same pattern as
issue.py:limit = keys[0][1](line 27) applies the first key's limit to every project in the batch. See the consolidated comment for the shared fix across all affected files.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/src/apps/github/api/internal/dataloaders/milestone.py` around lines 19 - 43, The load_recent_milestones_by_project_id function incorrectly applies keys[0][1] to every project. Update the query and result grouping to honor each (project_id, limit) pair independently, matching the shared fix used for the affected loaders while preserving the empty-input behavior.backend/src/apps/github/api/internal/dataloaders/pull_request.py (1)
13-37: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winUniform batch limit still assumed for
load_recent_pull_requests_by_project_id.
limit = keys[0][1](line 21) applies the first key's limit to every project in the batch. See the consolidated comment for the shared fix across all affected files.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/src/apps/github/api/internal/dataloaders/pull_request.py` around lines 13 - 37, Update load_recent_pull_requests_by_project_id so each project uses its own limit from the corresponding key instead of applying keys[0][1] to the entire batch. Preserve the per-project recent ordering and return grouping, and adjust the queryset/loading logic to enforce each key’s requested limit independently.
♻️ Duplicate comments (1)
backend/src/apps/github/api/internal/dataloaders/release.py (1)
17-46: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winUniform batch limit still assumed for
load_recent_releases_by_project_id.
limit = keys[0][1](line 25) applies the first key's limit to every project in the batch. See the consolidated comment for the shared fix across all affected files.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/src/apps/github/api/internal/dataloaders/release.py` around lines 17 - 46, Update load_recent_releases_by_project_id so each project is ranked and limited using its own key-specific limit instead of reusing keys[0][1] for the entire batch. Preserve the existing published-release filtering and per-project result grouping, and ensure the returned lists honor each requested limit.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@backend/src/apps/github/api/internal/dataloaders/issue.py`:
- Around line 19-43: Update load_recent_issues_by_project_id to support
per-project limits instead of applying keys[0][1] to the entire batch. Preserve
the window-function ranking, but apply each project’s requested limit when
filtering or assembling results, ensuring mixed-limit batches return the correct
number of issues for every project.
In `@backend/src/apps/github/api/internal/dataloaders/milestone.py`:
- Around line 19-43: The load_recent_milestones_by_project_id function
incorrectly applies keys[0][1] to every project. Update the query and result
grouping to honor each (project_id, limit) pair independently, matching the
shared fix used for the affected loaders while preserving the empty-input
behavior.
In `@backend/src/apps/github/api/internal/dataloaders/pull_request.py`:
- Around line 13-37: Update load_recent_pull_requests_by_project_id so each
project uses its own limit from the corresponding key instead of applying
keys[0][1] to the entire batch. Preserve the per-project recent ordering and
return grouping, and adjust the queryset/loading logic to enforce each key’s
requested limit independently.
---
Duplicate comments:
In `@backend/src/apps/github/api/internal/dataloaders/release.py`:
- Around line 17-46: Update load_recent_releases_by_project_id so each project
is ranked and limited using its own key-specific limit instead of reusing
keys[0][1] for the entire batch. Preserve the existing published-release
filtering and per-project result grouping, and ensure the returned lists honor
each requested limit.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b69606d6-b0e4-40f6-9344-784d0ac22f7a
📒 Files selected for processing (8)
backend/src/apps/github/api/internal/dataloaders/issue.pybackend/src/apps/github/api/internal/dataloaders/milestone.pybackend/src/apps/github/api/internal/dataloaders/pull_request.pybackend/src/apps/github/api/internal/dataloaders/release.pybackend/tests/unit/apps/github/api/internal/dataloaders/issue_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/milestone_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/pull_request_test.pybackend/tests/unit/apps/github/api/internal/dataloaders/release_test.py
arkid15r
approved these changes
Jul 22, 2026
arkid15r
merged commit Jul 22, 2026
79ee0f4
into
OWASP:feature/graphql-dataloaders
32 of 35 checks passed
This was referenced Jul 28, 2026
This was referenced Aug 11, 2026
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
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.
Proposed change
Resolves #5221
PoC
OWASP.ProjectNode.mp4
Tested Query
{ recentProjects(limit: 1000) { id recentMilestones { id title } recentIssues { id title } recentReleases { id tagName } recentPullRequests { id title } repositoriesCount issuesCount openIssuesCount topics languages forksCount healthMetricsList { id } healthMetricsLatest { id } repositories { id project { id } } } }Checklist