Small edgecase/regression here.
A changes feed for a single channel (N.B. not required to be single, but easier to demonstrate) would include backfills, except under the changes in
CBG-946 some of these backfills are not included as they are tombstones. The changes request specified a limit N, but no since value (issue still applies with since != 0, but again, easier to demo).
Up to N live documents are returned in the response. If <N documents are returned, this is because there are no more documents in the channel beyond what's been sent.
N-T documents are returned, where T is the number of backfill tombstones.
We pass the limit for the whole feed down to each channel - this way we get as small a query as we can reasonably run for each channel. E.g. if the limit is 5000, we ask each channel for up to 5000 and take the lowest 5000 across that union. You could get anything up to channels*5000 results, but we filter it in the changes level processing.
This is a problem if we're then discarding anything implicitly (like we now do under
CBG-946) because the limit has already been applied. IIRC we had similar issues in the Views era with active_only, and I notice we now pass that down and loop at the query level to prevent this issue there.
- Have a user with no access to channel bar:
- Add 5 docs to channel bar:
- Update them to create 5 tombstones:
- Give user access to bar
- Add a further document to bar:
- Request changes for user with limit <5 - observe that newest doc is not returned: