Skip to content

Commit 0694b84

Browse files
committed
Add some explanation comments
1 parent c080c6c commit 0694b84

File tree

1 file changed

+17
-7
lines changed

1 file changed

+17
-7
lines changed

src/sync.ts

Lines changed: 17 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -250,6 +250,11 @@ export class SyncApi {
250250
]);
251251
});
252252

253+
// When we see the marker state change in the room, we know there is
254+
// some new historical messages imported by MSC2716 `/batch_send`
255+
// somewhere in the room and we need to throw away the timeline to make
256+
// sure the historical messages are shown when we paginate `/messages`
257+
// again.
253258
room.currentState.on(RoomStateEvent.Marker, async function(
254259
markerEvent,
255260
{ fromInitialState }: ISetStateOptions = {},
@@ -298,19 +303,24 @@ export class SyncApi {
298303
);
299304
}
300305

306+
// It would be nice if we could also specifically tell whether the
307+
// historical messages actually affected the locally cached client
308+
// timeline or not. The problem is we can't see the prev_events of
309+
// the base insertion event that the marker was pointing to because
310+
// prev_events aren't available in the client API's. In most cases,
311+
// the history won't be in people's locally cached timelines in the
312+
// client, so we don't need to bother everyone about refreshing
313+
// their timeline. This works for a v1 though and there are use
314+
// cases like initially bootstrapping your bridged room where people
315+
// are likely to encounter the historical messages affecting their
316+
// current timeline (think someone signing up for Beeper and
317+
// importing their Whatsapp history).
301318
if (
302319
isValidMsc2716Event &&
303320
!markerAlreadyProcessed
304321
) {
305322
// Saw new marker event, let's let the clients know they should
306323
// refresh the timeline.
307-
//
308-
// It would be nice if we could lookup the base insertion event
309-
// that the marker event was pointing to because we really only
310-
// need to refresh the timeline if the timeline includes the
311-
// prev_events of the base insertion event and won't re-request
312-
// `/messages` over that range in the timeline. But the problem
313-
// is we can't see prev_events from the client API.
314324
logger.debug(
315325
`MarkerState: Timeline needs to be refreshed because ` +
316326
`a new markerEventId=${markerEvent.getId()} was sent in roomId=${room.roomId}`,

0 commit comments

Comments
 (0)