-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Add developer docs to explain pagination tokens #12305
Description
Add developer docs to explain pagination tokens.
The comment docs explain general things around the pagination tokens well but when I was confronted with s2633508_17_338_6732159_1082514_541479_274711_265584_1
, it wasn't obvious to me how to decipher it. I knew the stream_ordering
(s2633508
) part but it was really fuzzy what the other numbers were and the comment docs don't explain that part. I only really figured it out while drafting this issue and looking at the code more.
Relevant code:
Relevant endpoints:
/sync
?since
next_batch
prev_batch
/messages
?from
?to
start
end
- others
Live tokens (stream_ordering
)
Lines 436 to 437 in 3c41d87
Live tokens start with an "s" followed by the "stream_ordering" id of the | |
event it comes after. Historic tokens start with a "t" followed by the |
ex.
s2633508_17_338_6732159_1082514_541479_274711_265584_1
room_key
:s2633508
->2633508
stream_ordering
presence_key
:17
typing_key
:338
receipt_key
:6732159
account_data_key
:1082514
push_rules_key
:541479
to_device_key
:274711
device_list_key
:265584
groups_key
:1
s1_33_0_1_1_1_1_7_1
s843_0_0_0_0_0_0_0_0
Each number key are concatenated together in this order:
Lines 636 to 649 in 3c41d87
async def to_string(self, store: "DataStore") -> str: | |
return self._SEPARATOR.join( | |
[ | |
await self.room_key.to_string(store), | |
str(self.presence_key), | |
str(self.typing_key), | |
str(self.receipt_key), | |
str(self.account_data_key), | |
str(self.push_rules_key), | |
str(self.to_device_key), | |
str(self.device_list_key), | |
str(self.groups_key), | |
] | |
) |
And represent the position of the various fields in the /sync
response:
{
"next_batch": "s12_4_0_1_1_1_1_4_1",
"presence": {
"events": [
{
"type": "m.presence",
"sender": "@the-bridge-user:hs1",
"content": {
"presence": "offline",
"last_active_ago": 103
}
}
]
},
"device_lists": {
"changed": [
"@alice:hs1"
]
},
"device_one_time_keys_count": {
"signed_curve25519": 0
},
"org.matrix.msc2732.device_unused_fallback_key_types": [],
"device_unused_fallback_key_types": [],
"rooms": {
"join": {
"!QrZlfIDQLNLdZHqTnt:hs1": {
"timeline": {
"events": [],
"prev_batch": "s10_4_0_1_1_1_1_4_1",
"limited": false
},
"state": {
"events": []
},
"account_data": {
"events": []
},
"ephemeral": {
"events": []
},
"unread_notifications": {
"notification_count": 1,
"highlight_count": 0
},
"summary": {},
"org.matrix.msc2654.unread_count": 1
}
}
}
}
Historic tokens (topological_ordering
/depth
)
Lines 437 to 439 in 3c41d87
event it comes after. Historic tokens start with a "t" followed by the | |
"topological_ordering" id of the event it comes after, followed by "-", | |
followed by the "stream_ordering" id of the event it comes after. |
t175-530_0_0_0_0_0_0_0_0
topological_ordering
:t175
->175
(depth
)stream_ordering
:530
presence_key
:0
typing_key
:0
receipt_key
:0
account_data_key
:0
push_rules_key
:0
to_device_key
:0
device_list_key
:0
groups_key
:0
- You will see this from
/messages
probably because the endpoint is scoped to the room and so isdepth
topological_ordering
which is the same asdepth
in Synapse
Min-position tokens
This one seems pretty well explained by the comment docs already:
ex. m56~2.58~3.59
Lines 441 to 461 in 3c41d87
There is also a third mode for live tokens where the token starts with "m", | |
which is sometimes used when using sharded event persisters. In this case | |
the events stream is considered to be a set of streams (one for each writer) | |
and the token encodes the vector clock of positions of each writer in their | |
respective streams. | |
The format of the token in such case is an initial integer min position, | |
followed by the mapping of instance ID to position separated by '.' and '~': | |
m{min_pos}~{writer1}.{pos1}~{writer2}.{pos2}. ... | |
The `min_pos` corresponds to the minimum position all writers have persisted | |
up to, and then only writers that are ahead of that position need to be | |
encoded. An example token is: | |
m56~2.58~3.59 | |
Which corresponds to a set of three (or more writers) where instances 2 and | |
3 (these are instance IDs that can be looked up in the DB to fetch the more | |
commonly used instance names) are at positions 58 and 59 respectively, and | |
all other instances are at position 56. |