feat(FR-3075): paginate scheduling-history modals#7794
Conversation
The session/deployment/route scheduling-history modals fetched the entire history in one query with no pagination and fetchPolicy network-only, eagerly loading every row's subSteps. For entities with many scheduling cycles this produced a large server-side aggregation and re-fetched everything on each open, making these modals noticeably slower than the rest of the app. Add offset/table pagination to all three modals using useBAIPaginationOptionState (limit + offset only, per the V2-connection pagination rule), select the connection count for the total, and reset to page 1 on filter/order change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has required the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Coverage Report for react-coverage (./react)
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
There was a problem hiding this comment.
Pull request overview
Adds offset (page-number) pagination to the three scheduling-history modals (session / deployment / route) to avoid fetching and rendering an entire history (including per-row subSteps) on every modal open, improving responsiveness for long-running entities.
Changes:
- Added
$limit/$offset+countto the session/deployment/route scheduling-history queries and wired table pagination (total: count). - Session modal now uses
useBAIPaginationOptionStatedirectly with deferredlimit/offsetinuseLazyLoadQuery. - Deployment/route modals (preloaded-query pattern) now own page state and refetch via existing
onReload; openers seed initialloadQuerywith{ limit: 10, offset: 0 }. Filter/order changes reset to page 1.
Reviewed changes
Copilot reviewed 5 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| react/src/components/SessionSchedulingHistoryModal.tsx | Adds limit/offset pagination args to the query and wires useBAIPaginationOptionState + BAITable pagination with count. |
| react/src/components/RouteSchedulingHistoryModal.tsx | Adds limit/offset/count to the preloaded query and refetches on page change via onReload, resetting offset on filter/order changes. |
| react/src/components/DeploymentSchedulingHistoryModal.tsx | Same as route modal: adds limit/offset/count and table pagination-driven refetch behavior. |
| react/src/components/DeploymentReplicasTab.tsx | Seeds initial route history modal query variables with { limit: 10, offset: 0 } when opening. |
| react/src/components/DeploymentConfigurationSection.tsx | Seeds initial deployment history modal query variables with { limit: 10, offset: 0 } when opening. |
| react/src/generated/SessionSchedulingHistoryModalQuery.graphql.ts | Relay artifact updated for new pagination variables and count selection. |
| react/src/generated/RouteSchedulingHistoryModalQuery.graphql.ts | Relay artifact updated for new pagination variables and count selection. |
| react/src/generated/DeploymentSchedulingHistoryModalQuery.graphql.ts | Relay artifact updated for new pagination variables and count selection. |
Files not reviewed (3)
- react/src/generated/DeploymentSchedulingHistoryModalQuery.graphql.ts: Language not supported
- react/src/generated/RouteSchedulingHistoryModalQuery.graphql.ts: Language not supported
- react/src/generated/SessionSchedulingHistoryModalQuery.graphql.ts: Language not supported

Resolves #7793 (FR-3075)
Summary
The scheduling-history modals (session, deployment, route) added in #7650 fetched the entire scheduling history in a single query with no pagination arguments and
fetchPolicy: 'network-only', eagerly loading every row'ssubSteps. For sessions/deployments/routes that went through many scheduling cycles (retries, rescheduling), this produced a large server-side aggregation and re-fetched the whole thing on every modal open — making these modals noticeably slower than the rest of the app.This adds offset (page-number) pagination to all three modals.
Changes
SessionSchedulingHistoryModal(self-containeduseLazyLoadQuery): add$limit/$offsetto the query, selectcount, wireuseBAIPaginationOptionStatewith deferredlimit/offset, and pass the tablepaginationconfig.DeploymentSchedulingHistoryModal/RouteSchedulingHistoryModal(preloaded-query pattern): add$limit/$offset+countto the query; the modal owns page state and calls the existingonReloadwith newlimit/offseton page change. Their openers (DeploymentConfigurationSection,DeploymentReplicasTab) seed the initialloadQuerywithlimit: 10, offset: 0.offset: 0).limit+offsetonly — the three*ScopedSchedulingHistoriesare Strawberry V2 connections that reject mixedfirst+offsetat runtime (see.claude/rules/graphql-pagination.md).Behavior note
With pagination, the FR-3008 "expand errors only" default auto-expands non-success rows on the current page only, not across the whole history. This is the expected trade-off for paginated tables.
Verification
bash scripts/verify.sh→ Relay / Lint / Format / TypeScript all pass (the Relay step only flags the regenerated__generated__artifacts as needing commit, which are included in this PR).🤖 Generated with Claude Code