[AliAlfaifi]

Summary

Every response of the bulk progress feed (GET /api/fx/learners/v1/learner_courses/, no username) now has two new fields:

• count: the total rows the whole walk returns.
• page: 1 for the first call, then +1 per next.

{"count": 86819, "page": 1, "next": "...", "previous": null, "results": [...]}

How the count stays cheap

• It is a COUNT over the feed's own filters, without the per-row columns (get_learners_progress_count; the filters are shared through _get_learners_progress_base).
• It runs once, on the call without a cursor, and is carried in the cursor as after:page:count. Later pages never count again.
• Old cursors keep working. Cursors issued by v0.13.8 (a bare id) still walk to the end; their walks report count and page as null.

Known cost (not measured)

The first call counts the caller's whole scope. For the largest tenants (millions of enrollments) that call will be noticeably slower than today; it has not been timed on the prod replica. Pages after the first are unchanged.

Tests

tox -e py311-teak,py311-redwood,py311-sumac,quality: 100% coverage in each release, quality clean. New cases cover:

• count equals the rows actually walked and is the same on every page; page goes 1..N;
• the count is computed once per walk;
• count follows modified_since;
• an empty table gives count 0;
• an old cursor still walks;
• malformed cursors return 404;
• the paginator falls back to queryset.count() when the view has no counter.

The existing learner_courses/<username>/ route is untouched.

🤖 Generated with Claude Code