@@ -366,14 +366,24 @@ class MarkAsReadWidget extends StatelessWidget {
366
366
await showErrorDialog (context: context,
367
367
title: zulipLocalizations.errorMarkAsReadFailedTitle,
368
368
message: e.toString ());
369
+ return ;
370
+ }
371
+ if (! context.mounted) return ;
372
+ if (narrow == const AllMessagesNarrow ()) {
373
+ // We've learned that the mark-all-as-read work succeeded, so we know
374
+ // there can't be ancient unreads we don't know about. Update the
375
+ // Unreads model to reflect that.
376
+ //
377
+ // [Unreads] is supposed to do this naturally, in
378
+ // handleUpdateMessageFlagsEvent. That's based on the documented behavior
379
+ // that a completed mark-all-as-read task gets signaled by `all: true` on
380
+ // the [UpdateMessageFlagsAddEvent]. But when using this new batch-
381
+ // processing protocol, it seems clients have to track progress and
382
+ // success themselves; the event from the last batch is unmarked.
383
+ // Discussion:
384
+ // <https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/flutter.3A.20Mark-as-read/near/1680275>
385
+ PerAccountStoreWidget .of (context).unreads.oldUnreadsMissing = false ;
369
386
}
370
- // TODO: clear Unreads.oldUnreadsMissing when `narrow` is [AllMessagesNarrow]
371
- // In the rare case that the user had more than 50K total unreads
372
- // on the server, the client won't have known about all of them;
373
- // this was communicated to the client via `oldUnreadsMissing`.
374
- //
375
- // However, since we successfully marked **everything** as read,
376
- // we know that we now have a correct data set of unreads.
377
387
}
378
388
379
389
@override
0 commit comments