morethanwords/tweb/master • 6f3299c • 6 files, +162/-26 Update the account badge when the messages a

morethanwords/tweb/master • 6f3299c • 6 files, +162/-26
Update the account badge when the messages are read elsewhere

The badge next to every other account in the main menu counts the notifications
shown for it, and that count lives in a storage shared by all tabs — but only
the tab that had shown a notification could take it back: cancel() decremented
it exclusively while the key was still in its in-memory notificationsShown. A
reload, a second tab, or a read that came from another client dropped that
claim, and since start() only zeroes the account you are on, the badge of the
others stayed stuck for good.

Keep the pending notification keys themselves instead of a bare number and
derive the count from them. Cancelling becomes idempotent and shared, so
whichever tab hears about the read first is the one that drops the key. The
cancels arrive one per message, so they are batched into a single write.

notification_cancel can only be fired for messages that are in memory, which is
not the case for a peer whose history hasn't been loaded yet — exactly what a
read arriving right after a restart hits. So onUpdateReadHistory now also emits
notification_cancel_up_to and the whole read range is dropped at once. Thread
reads are left out of it: they share the message id space with the rest of the
peer, and applying one as a range would cancel notifications of threads nobody
has read.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

morethanwords/tweb/master • 37e6736 • 3 files, +157/-10
Load every topic in a big forum

The topic list froze after the first server page: a forum with 197 topics
showed 101 and stopped there. Topics were paginated with the folder's global
offset date, which is derived from the peer's own history — something a topic
list has nothing to do with — so for a forum it stayed 0, every next page
repeated the very first request, and the response brought nothing new.

Paginate the way the official clients do instead: with the offsets of the LAST
topic of the previous page — its top message's date and id, plus the topic id.
messages.getForumTopics gets the whole triple now, so topics sharing a
top-message date can't collapse the cursor either, and offset_topic finally
carries a server id (the search path used to send the local, offset-encoded
one, which doesn't even fit an int32). The botforum special case that patched
the same freeze with the topic's creation date folds into this path.

Forum topics also stop writing the folder's global offset date: it came from
the forum's own history, so once that history was cached it was not only
useless as a cursor but could drop topics in pushDialog.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

morethanwords/tweb/master • c934ddd • 8 files, +57/-9
Don't crash on a mid without a message behind it

A cached (non-global) search returns only mids, so the tab resolves each one
via apiManagerProxy.getMessageByPeer. A mid can outlive its message — deleted,
or a synthetic migration bound inserted by mergeHistoryResult — and the
resulting hole was fed straight into the consumers, throwing on message.mid.

Skip such holes in ListLoader before processItem, in both search-result
renderers and the shared media tab, and stop looking up a message just to read
back a mid the search key already holds.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

#webk