Testing continuation cursors after the requesting identity changes

Goal

Check the application’s visibility policy when a continuation cursor is reused under a different principal. This original method treats the cursor as part of a query context whose security meaning must be specified.

Prerequisites

Create a paginated synthetic collection with records visible to different accounts. Define whether cursors are reusable across callers and whether each page must evaluate the current caller’s visibility independently.

Steps

1. Fetch an initial page as the permitted account and follow its continuation normally. Confirm that the fixture spans multiple pages and that the expected records actually appear.

2. Use the same continuation under a less-privileged synthetic account through the supported client interface. Inspect returned records, counts, and metadata against that caller’s visibility policy.

3. Change the original caller’s membership between pages and follow the saved cursor again. Compare the result with the documented policy for changes that occur during traversal.

4. Attempt to combine the cursor with a different supported filter or workspace context. Decide whether the contract rejects the combination or reevaluates it, and inspect the actual resulting records.

5. After repair, repeat valid traversal and changed-principal cases. Keep ordering and fixture contents deterministic so missing records can be distinguished from access-control decisions.

Expected result

A useful regression shows that every page obeys its documented caller and query context, including the behavior when that context changes after the cursor was issued.

Limits and test basis

This method does not prescribe cursor encoding or claim that reusable cursors are inherently unsafe. Snapshot consistency and concurrent inserts are separate concerns requiring their own pagination contract. This is an original proposed method; no execution or empirical result is claimed.