fix: page backward in autoPagination after a before cursor

[tribble]

I hit this with autoPagination() on a list fetched with before: page 2 sends both before and after, and the API rejects it with Please provide either "after" or "before" parameters.

• A list fetched with before now keeps paging backward through listMetadata.before, and every request sends only that one cursor.
• Backward results come back in reverse stream order: listUsers({ before: 'u21' }) yields u20, u19, …, u1.

Test plan

• RED on origin/main (new spec, production code unmodified): paginates backward when a before cursor is specified fails — results come back unreversed in forward stream order ([u3,u4,u1,u2] instead of [u4,u3,u2,u1]); the run aborts on that assertion before the request-param checks.
• GREEN on this branch: npm test -- src/common/utils/pagination.spec.ts --runInBand — 6/6 pass, proving the reversed result order and the exact params of every API call (only before sent, never both cursors).

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Adds backward pagination support to the pagination utility.

The PR should not merge until backward results preserve the requested ordering.

Findings

1.  Backward pages reverse requested order ▶
2.  Limited backward results differ ▶
3.  Conflicting cursor is silently dropped ▶

Fix with agent prompt

### Issue 1
src/common/utils/pagination.ts:43-45
If the API returns a page in the requested descending order, `autoPagination()` reverses that page and emits its items ascending instead. The new test requests `order: 'desc'` but mocks ascending page data, so it does not catch this result-order failure.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

### Issue 2
src/common/utils/pagination.spec.ts:53-56
With both `before` and `limit`, `autoPagination()` returns the initial page unchanged, while the new backward-pagination path reverses its pages. This test locks in different result orders for the same kind of request depending on whether a limit is set, making callers handle two ordering behaviors.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

### Issue 3
src/common/utils/pagination.ts:34-40
If a caller supplies both `before` and `after`, the new direction check selects forward pagination and this request drops `before`. The caller gets results for `after` alone instead of the API error for conflicting cursors, making the invalid request harder to diagnose.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR makes autoPagination() follow listMetadata.before for backward pagination, send only one cursor per request, and reverse backward page data.

• It adds tests for backward traversal, cursor parameters, and limited backward requests.
• The ordering logic and handling of conflicting cursors need attention.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A["autoPagination()"] --> B{"limit supplied?"}
  B -- Yes --> C["Return initial data unchanged"]
  B -- No --> D{"before set and after absent?"}
  D -- Yes --> E["Request with before; reverse page; follow metadata.before"]
  D -- No --> F["Request with after; retain page order; follow metadata.after"]

Loading

_{Reviews (1) · Last reviewed commit: "fix: page backward in autoPagination aft..."}

[greptile-apps]

Backward pages reverse requested order If the API returns a page in the requested descending order, autoPagination() reverses that page and emits its items ascending instead. The new test requests order: 'desc' but mocks ascending page data, so it does not catch this result-order failure.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/common/utils/pagination.ts
Line: 43-45

Comment:
**Backward pages reverse requested order** If the API returns a page in the requested descending order, `autoPagination()` reverses that page and emits its items ascending instead. The new test requests `order: 'desc'` but mocks ascending page data, so it does not catch this result-order failure.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Limited backward results differ With both before and limit, autoPagination() returns the initial page unchanged, while the new backward-pagination path reverses its pages. This test locks in different result orders for the same kind of request depending on whether a limit is set, making callers handle two ordering behaviors.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/common/utils/pagination.spec.ts
Line: 53-56

Comment:
**Limited backward results differ** With both `before` and `limit`, `autoPagination()` returns the initial page unchanged, while the new backward-pagination path reverses its pages. This test locks in different result orders for the same kind of request depending on whether a limit is set, making callers handle two ordering behaviors.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Conflicting cursor is silently dropped If a caller supplies both before and after, the new direction check selects forward pagination and this request drops before. The caller gets results for after alone instead of the API error for conflicting cursors, making the invalid request harder to diagnose.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/common/utils/pagination.ts
Line: 34-40

Comment:
**Conflicting cursor is silently dropped** If a caller supplies both `before` and `after`, the new direction check selects forward pagination and this request drops `before`. The caller gets results for `after` alone instead of the API error for conflicting cursors, making the invalid request harder to diagnose.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.