UnigramDev/Unigram/develop • c715efe • 3 files, +30/-8 Stop asking the server for the synthetic topi

UnigramDev/Unigram/develop • c715efe • 3 files, +30/-8
Stop asking the server for the synthetic topic row

Both GetTopics implementations yield a synthetic row for a sentinel id — the
"All topics" entry, or the new-topic prompt in a bot chat — and then fall
through to GetTopic with that same sentinel. In the forum service that fires
getForumTopic for id 2147483647, and the failure then sits in _pendingNewTopics
for the life of the service, since a 4xx is deliberately not retried. One wasted
round trip per forum opened, and a permanently poisoned entry.

A continue in each. The direct-messages one was harmless today only because its
GetTopic is cache-only rather than fetching, which is not a property worth
relying on.

Left alone deliberately: the four allocations per enumeration for that synthetic
row. The review called it a constant to hoist into a field, and it is not one.
Its label comes from Strings.AllTopicsShort, which is a live Resource.GetString
call, and the app applies updateLanguagePackStrings at runtime while a
ForumTopicService lives until logout. A hoisted field would keep showing the
previous language for the rest of the session. Four allocations on a list
enumeration is not worth a visibly wrong string.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 90c8623 • 1 files, +23/-16
Downgrade GetChatFromMessageSenderAsync: it is not a bug

The review claimed the method returns null for every chat sender as though the
chat were meant to be returned. Read on its own it does one coherent thing:
resolve a user sender to its private chat, creating it if needed, and return null
for anything else. For a MessageSenderChat both paths return null, found or not
found, so there is no inconsistency and nothing is dropped.

What is really there is a vestigial first line. TryGetChat(messageSender, out
chat) has its return value discarded and its out value can only be non-null in
exactly the case the following if excludes, so it is dead on every path — and it
is what makes the method read as though chat senders were handled.

Kept in the doc at P3 with a note on how the wrong conclusion was reached: the
reasoning followed the cached branch, saw the value discarded, and stopped,
without checking that the uncached branch returns null too — which is what shows
the behaviour is uniform and deliberate. Reading the call sites afterwards made
it look confirmed, since a channel receiver really does get null; that just is
not a defect, because the purchase uses the sender directly and succeeds, and the
chat only picks which toast is shown.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 6de9291 • 3 files, +30/-47
Fix leak instrumentation

#unigram