Revert "fix(dashboard): fix pagination (#4083)"

[jog1t]

This PR reverts commit 337e20b which fixed pagination in the dashboard.

[railway-app]

🚅 Deployed to the rivet-pr-4085 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	🕐 Initializing (View Logs)	Web	Jan 31, 2026 at 2:16 am
frontend-inspector	🕐 Initializing (View Logs)	Web	Jan 31, 2026 at 2:16 am
mcp-hub	🕐 Initializing (View Logs)	Web	Jan 31, 2026 at 2:16 am
frontend-cloud	🕐 Initializing (View Logs)	Web	Jan 31, 2026 at 2:16 am

[claude]

PR Review: Revert Pagination Fix

Summary

This PR reverts commit 337e20b (PR #4083) which implemented cursor-based pagination for the dashboard. The revert changes pagination back from cursor-based to offset-based for namespaces and projects.

Key Changes

1. Namespace Pagination (lines 108-130)

Reverted from: Cursor-based pagination with proper pagination.cursor handling
Back to: Offset-based pagination using manual calculation

Concerns:

• The reverted code uses offset-based pagination (offset: pageParam ? Number.parseInt(pageParam, 10) : undefined) which is less efficient for large datasets
• The getNextPageParam logic manually calculates offsets by summing all previous pages, which is error-prone
• Returns a hardcoded empty pagination object { cursor: undefined } instead of using the actual API response
• Hardcoded limit of 100 instead of using RECORDS_PER_PAGE constant

2. Projects Pagination (lines 137-152)

Similar reversion from cursor-based to offset-based pagination with the same concerns.

3. Removed Engine Namespace Override (lines 612-648)

The revert removes a large block of code that was overriding namespacesQueryOptions for engine namespaces. This code appeared to handle pagination type mismatches between cloud and engine APIs.

Impact: Unclear why this override was removed. This could cause type or runtime errors if the engine API returns different pagination structures.

4. Dependencies

Updates @rivet-gg/cloud package from commit 632b0c3 to 199a6ff (older version), suggesting the original pagination fix may have depended on API changes.

Issues & Recommendations

Critical Issues

1. Missing context: The PR description doesn't explain WHY the pagination fix is being reverted. Was it causing bugs? Performance issues? Breaking changes?

2. Offset pagination inefficiency: Offset-based pagination has known issues:

   • Poor performance on large datasets (database has to scan all skipped rows)
   • Prone to duplicate/missing items when data changes between page loads
   • Industry best practice is cursor-based pagination

3. Magic numbers: Hardcoded limit: 100 for namespaces instead of using RECORDS_PER_PAGE (which is 25 based on the projects query)

4. Inconsistent limits: Namespaces use 100, projects use RECORDS_PER_PAGE. Should be consistent.

5. Type safety: Returning { cursor: undefined } as pagination could cause TypeScript issues if consumers expect a proper pagination object.

Questions for Author

• What specific issue prompted this revert?
• Were there test failures or user-reported bugs?
• Is there a plan to re-implement cursor-based pagination correctly?
• Why downgrade the @rivet-gg/cloud dependency?

Recommendations

1. Add PR context: Update the PR description with specific reasons for the revert
2. Test coverage: Add tests to prevent pagination regressions
3. Follow-up plan: Document plans to address the underlying issue and restore proper pagination
4. Consider partial revert: If only specific parts were problematic, consider reverting only those portions

Code Quality Notes

• Style compliance: Changes follow existing patterns but reintroduce technical debt
• No new bugs introduced: The code returns to a previously working state
• Testing: No test changes included - unclear if pagination is covered by tests

Verdict

⚠️ Approval with reservations

While the code itself is functional (reverting to a known working state), this PR lacks the context needed to understand if this is the right solution. Before merging:

1. Document why the original fix is being reverted
2. Create a follow-up issue to track proper pagination implementation
3. Consider if this impacts users with large datasets (>100 namespaces)

---

Review generated with Claude Code - let me know if you need clarification on any points.

[graphite-app]

Graphite Automations

"Test" took an action on this PR • (01/31/26)

1 assignee was added to this PR based on Kacper Wojciechowski's automation.