bug: Filtered `/relations` returns short pages without `next_batch` because the `limit` is applied before filters #2470

New issue

Closed

opened 2026-11-07 15:56:22 +00:00 by Henry-Hiles · 0 comments

Henry-Hiles commented

2026-11-07 15:56:22 +00:00

Member

What is the bug?

When /relations is called with a rel_type or event_type filter, the server can return a short page with no next_batch, even though more matching relations exist. The client has no way to fetch the rest.

This happens because the limit is applied before the filters. pdu_metadata::get_relations collects all direct relations, then walks deeper levels and stops once its result count reaches limit (pdu_metadata/mod.rs#L108-L111). That count includes relations of every type. The filters only run afterwards, in the endpoint (relations.rs#L156-L171).

Steps to reproduce

Send a message and start a thread on it with at least 5 replies.
React to several of the thread replies
Call GET /_matrix/client/v1/rooms/{roomId}/relations/{T}/m.annotation?recurse=true&limit=5.
You'd expect up to 5 reactions, with a next_batch if there are more. But you actually get at most 1 reaction and no next_batch.

Server name and version

federated.nexus + local repro, 02aed4fb23

Additional context

 		.filter(|(_, pdu)| {
 			filter_event_type
 				.as_ref()
 				.is_none_or(|kind| kind == pdu.kind())
 		})
 		.filter(|(_, pdu)| {
 			filter_rel_type
 				.as_ref()
 				.is_none_or(|rel_type| rel_type.relation_type_equal(pdu))
 		})
 		.stream()

 				pdus.push(relation);
 				if pdus.len() >= limit {
 					break 'limit;
 				}

### What is the bug? When `/relations` is called with a `rel_type` or `event_type` filter, the server can return a short page with no `next_batch`, even though more matching relations exist. The client has no way to fetch the rest. This happens because the limit is applied before the filters. `pdu_metadata::get_relations` collects all direct relations, then walks deeper levels and stops once its result count reaches `limit` ([pdu_metadata/mod.rs#L108-L111](https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/02aed4fb23504f54ed068c51175959c2cc71d8d0/src/service/rooms/pdu_metadata/mod.rs#L108-L111)). That count includes relations of every type. The filters only run afterwards, in the endpoint ([relations.rs#L156-L171](https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/02aed4fb23504f54ed068c51175959c2cc71d8d0/src/api/client/relations.rs#L156-L171)). ### Steps to reproduce 1. Send a message and start a thread on it with at least 5 replies. 2. React to several of the thread replies 3. Call `GET /_matrix/client/v1/rooms/{roomId}/relations/{T}/m.annotation?recurse=true&limit=5`. 4. You'd expect up to 5 reactions, with a `next_batch` if there are more. But you actually get at most 1 reaction and no `next_batch`. ### Server name and version federated.nexus + local repro, https://forgejo.ellis.link/continuwuation/continuwuity/commit/02aed4fb23504f54ed068c51175959c2cc71d8d0 ### Additional context https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/02aed4fb23504f54ed068c51175959c2cc71d8d0/src/api/client/relations.rs#L159-L169 https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/02aed4fb23504f54ed068c51175959c2cc71d8d0/src/service/rooms/pdu_metadata/mod.rs#L108-L111

Henry-Hiles added the

Bug

Status

Needs Investigation

labels

2026-11-07 15:56:22 +00:00

Henry-Hiles referenced this issue from a pull request that will close it,

2026-11-07 15:57:28 +00:00

fix: Correct relations pagination and recursion #2465