Bound total-count work independently of result pagination
A fast first page still waits for an expensive exact count.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Query performance
Estimated field mix
- Performance engineering50%
- Database engineering30%
- API design20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional logistics platform lists shipments for partner dashboards. Offset pagination duplicates records during updates, while unrestricted filters create expensive database queries.
Setup prerequisites
- Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- BAPIPAGE-101 · Define supported shipment filters and their exact semantics
- BAPIPAGE-102 · Validate bounded sort options instead of accepting SQL fragments
- BAPIPAGE-103 · Enforce tenant scope before applying user filters
- BAPIPAGE-104 · Encode opaque cursors bound to the normalized query
- BAPIPAGE-105 · Use keyset traversal for shipments sharing timestamps
Acceptance criteria
- Make count behavior explicit and optional if appropriate.
- Bound count execution time.
- Distinguish unavailable or estimated totals from exact totals.
Implementation constraints
- Never label an estimate as an exact count.
Verification to include
- Return a page without optional count work.
- Timeout count calculation without misreporting zero results.
Deliverables
- Count contract.
Rollout and recovery
Default to the least expensive contract satisfying the use case.
Value of the work
For the engineer: Practice cursor design, query contracts, and consistency/performance tradeoffs.
For the team: Provide predictable list APIs that remain bounded and preserve tenant scope.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.