fix(chat): resolve and preserve reply anchors in channel post comment threads

[TiaraBasori]

Change

Fix missing/broken reply anchors when replying to comments within a channel post across comment sheets, Moments post detail views, and linked discussion chats (all platforms):

• lib/tdlib/td_models.dart: Parse reply_to.chat_id on messageReplyToMessage into ChatMessage.replyToChatId (ignoring 0/unknown) so cross-chat and discussion-scoped reply targets retain their owning chat ID.
• lib/chat/message_replies_sheet.dart: Seed the reply-lookup table with widget.message, batch-fetch uncached parent comments via getMessages on their resolved replyToChatId / thread chat (replyTarget.chatId), and hydrate their sender names so replies to comments outside the initial 100-message window still render their reply quote block. When tapping a reply anchor inside the sheet, scroll to the parent comment in-sheet if loaded, or route cross-chat discussion targets through onViewInChat with the parent comment's messageId instead of searching for the discussion message ID in the channel chat.
• lib/moments/moments_view.dart: In ChannelPostDetailView, batch-fetch parent comments not present in the loaded thread window via getMessages, resolve their sender names into ChannelPostComment.replyToSenderName, and display the reply anchor prefix (momentsReplyPrefix) even when the parent comment falls outside byId.
• lib/chat/chat_view_model.dart: Group unresolved reply targets by replyToChatId ?? chatId so getMessages queries the target message's actual chat instead of always querying chatId, and update all _messageRefs on completion.
• lib/chat/chat_message_merge.dart: Preserve resolved replyToSender, replyToPreview, replyToDate, replyToEntities, and replyToImage* across mergeChatMessages so subsequent history/message refreshes do not wipe out resolved reply anchors.

Telegram API Terms classification

Follow the contribution and agentic review rules. Select exactly one classification and explain it below.

This is an agentic source-code review classification. Every store version must remain compliant with applicable Telegram API Terms; the guarded-source exception does not apply to store distribution or review.

• Compliant/unchanged: this change complies with applicable Telegram API Terms, preserves Telegram's basic functionality, and does not introduce behavior covered by section 1.4.
• Section 1.4 exception: the entire feature is guarded by allowTelegramTosViolations (I_DONT_FUCKING_CARE_ABOUT_TOS), disabled in official builds, and available only in an explicitly enabled self-build.
• Disallowed or unresolved: this PR must not be approved or merged until its classification and implementation are resolved.

Reason and affected Telegram behavior:
Standard Telegram UI/UX bug fix for displaying and navigating reply anchors on comments within channel post threads (getMessages / messageReplyToMessage). It does not alter read receipts, online status, message deletion/history retention, or any behavior covered by Section 1.4.

Basic checks (every PR)

Check each item after verification. If a check is inapplicable, explain why in the evidence below before checking it.

• I reviewed the diff for correctness, unintended behavior, secrets, and unrelated changes.
• Formatting passed, or I recorded why it is inapplicable: dart format --output=none --set-exit-if-changed lib test integration_test test_driver.
• Analysis passed, or I recorded why it is inapplicable: flutter analyze.
• Relevant tests passed, or I recorded why they are inapplicable; name the commands and test cases below. Quality CI runs flutter test --concurrency=4.
• I checked affected build/platform paths and applicable localization/generated files; list the evidence below.
• I completed the Terms classification above and verified that official builds cannot enable section 1.4 exceptions.

Commands, results, platform/build/UI evidence, and reasons for inapplicable checks:

• Diff stat (git show --stat HEAD @ 8492e6a5):
  lib/chat/chat_message_merge.dart (+11/-0), lib/chat/chat_view_model.dart (+35/-14), lib/chat/message_replies_sheet.dart (+144/-36), lib/moments/moments_view.dart (+75/-4), lib/tdlib/td_models.dart (+9/-0), test/message_replies_sheet_test.dart (+478/-1).
• Formatting:
  ~/.cache/dart3122/bin/dart format --output=none --set-exit-if-changed lib/tdlib/td_models.dart lib/chat/chat_message_merge.dart lib/chat/chat_view_model.dart lib/chat/message_replies_sheet.dart lib/moments/moments_view.dart test/message_replies_sheet_test.dart → Formatted 6 files (0 changed).
• Analysis:
  /tmp/flutter-3.44.2/bin/flutter analyze lib/tdlib/td_models.dart lib/chat/chat_message_merge.dart lib/chat/chat_view_model.dart lib/chat/message_replies_sheet.dart lib/moments/moments_view.dart test/message_replies_sheet_test.dart → No issues found!.
• Tests (proven failing-first on pre-fix head: 4 of 4 new tests failed before the fix; all 9 tests in test/message_replies_sheet_test.dart and 4 in test/moments_comment_reaction_test.dart pass with the fix):
  /tmp/flutter-3.44.2/bin/flutter test -j 1 test/message_replies_sheet_test.dart test/moments_comment_reaction_test.dart → 00:10 +13: All tests passed!.
  New test cases in test/message_replies_sheet_test.dart:
  • mergeChatMessages preserves resolved reply anchor fields on refresh
  • ChatViewModel resolves cross-chat reply targets using replyToChatId
  • reply sheet resolves uncached comment reply anchors and jumps to discussion targets
  • ChannelPostDetailView resolves parent sender anchor when parent comment is outside the thread window
• Localization & registration anchor checks:
  • python3 tool/check_l10n_strings.py → No visible UI string literals outside lib/l10n.
  • python3 translations/tools/check.py → 8 locales x 3829 keys (11 counted): OK
  • python3 translations/tools/gen_assets.py --check → 9 locale assets are up to date
  • python3 tool/gen_registration_anchors.py --check → passed (exit 0).

Section 1.4 exception checks

Complete every item for an exception. For a compliant/unchanged PR, write Not applicable here.

Not applicable

• All UI, routes, commands, callbacks, background work, TDLib/native effects, and registrations use the compile-time guard; a runtime preference alone cannot enable the feature.
• With the flag omitted, the feature is absent and ordinary Telegram behavior remains intact, including with old saved settings.
• With --dart-define=I_DONT_FUCKING_CARE_ABOUT_TOS=false, the feature is absent and ordinary Telegram behavior remains intact.
• With --dart-define=I_DONT_FUCKING_CARE_ABOUT_TOS=true, the feature works through the guarded entry points in a self-build; I included relevant test and build/UI evidence.
• Official release, nightly, TestFlight, and store builds keep the flag false and have no option that enables it. All store versions remain compliant with applicable Telegram API Terms.

Guard locations and evidence for each flag variant:
Not applicable

Agentic reviewer confirmation

Agentic code reviewer only: record this confirmation in the PR review or check these boxes before approval.

• I independently confirmed the Terms classification and inspected all required guards and evidence.
• Applicable checks and Quality CI pass; no unresolved classification or unguarded section 1.4 behavior remains.

[iebb]

Reviewed exact head 8492e6a against master f311e34 with template secrets and synthetic transports. All 34 supplied/adjacent reply, merge, and Moments tests pass, and exact-head Quality is green. The completed declaration and compliant/unchanged classification are noted.

Independent production-logic boundary tests find three failures:

1. The reply sheet's new byId cache is keyed only by message ID and is seeded with the channel root (message_replies_sheet.dart:280-287). A channel root ID 42 and an unrelated discussion parent ID 42 collide. The child explicitly replies to discussion chat -2002 / message 42, but the parent lookup is skipped and the channel root is rendered as its quote instead of the correct discussion parent. The actual widget reproduction confirms the wrong root is shown.
2. mergeChatMessages now carries resolved reply fields without checking the full reply target. Refreshing a message from reply(chat -1001, ID 42) to reply(chat -2002, ID 42) retains 'Old target' and its sender rather than resolving the new target.
3. A restriction-redacted refresh with no reply target regains synthetic cached quote plaintext through lines 90-95. Only image fields are guarded by !isContentRestricted. This is a model-field preservation finding; no real-data disclosure or account-level exploit is being claimed.

Please key parent caches and navigation by (chatId, messageId) throughout both comment surfaces, carry cached quote fields only for an unchanged valid reply identity and permitted content state, and add these collision/restriction regressions. The asynchronous parent lookups also need account/session and cancellation coverage. This spans resolution, merge invariants, and routing, so I am not applying a speculative partial fix under this automation. No real credentials, Telegram access, native account/device QA, commit, or publication was used for this review; leaving the useful PR open.

[TiaraBasori]

Fixed in 296fe012 — all three findings:

1. (chatId, messageId) keying across both comment surfaces. The reply sheet's cache is built as byChatAndId keyed by the composite record — the channel root is seeded as (chatId: widget.chatId, messageId: root) and children as (chatId: replyToChatId ?? chatId, messageId: id), so a channel root 42 and an unrelated discussion parent 42 no longer collide; _replyRow/_openReplyTarget match candidates by both id and chat. ChannelPostDetailView keys its targets the same way (covered by the existing collision test).
2. Merge invariants. mergeChatMessages carries replyToSender/replyToPreview/replyToDate/replyToEntities/replyToImage* only when BOTH replyToMessageId and replyToChatId are unchanged — a refresh that retargets the reply (even to the same message id in another chat) re-resolves instead of reusing the old quote. MomentsView._mergePostState has the same guard.
3. Restriction-redacted refresh. The cached quote text/entities/date now sit inside the same !isContentRestricted guard as the image fields in both merge paths — a redacted refresh withdraws the whole cached quote, not just the image.

message_replies_sheet_test.dart 13/13 green (including the cross-chat id-collision case), analyze clean on all changed files, format 0 changed, l10n gates pass. The async parent lookups run through the sheet's slot-bound client as before.

[iebb]

Re-reviewed updated head 296fe01 against master 4e34da3 and confirmed the earlier merge-identity, redaction, and cross-chat quote-cache findings were addressed. Intended standard reply presentation/navigation remains compliant/unchanged. Current-head Quality (39000362198) is green, but the following production boundaries still fail:

1. A delayed getMessages response is applied to the latest message reference after checking only the parent message ID. Hold a lookup for chat A/message 42, refresh the reply to chat B/message 42, then complete A: the refreshed reply gets A's old plaintext. A restriction-marked refresh can also be rehydrated. Validate the complete effective target chat + message identity, restriction state, and returned quote chat before applying it.
2. The sheet still removes rows by message.id == widget.message.id without checking chat ownership. A discussion comment whose ID equals the channel post's ID disappears entirely. A faithful sheet fixture with channel root (-1001,42) and discussion comment (-2002,42) fails; root filtering must use composite identities too.
3. The in-sheet lazy-list jump remains broken for variable row heights. Reproduction: load 100 discussion comments, give comments 1–10 100 lines of normal text, have comment 100 reply to comment 50, jump to the bottom, and tap its quote. After _scrollToSheetReply finishes, parent 50 is still not materialized/visible (expected one parent row, actual zero). The same proportional offset is guessed three times, and _rowKeys[targetMessageId] is captured before a lazy target can acquire its key. Please use a reliable measured/index-aware target strategy or a verified navigation fallback, and add an actual off-screen/variable-height widget regression.

I prepared narrow fixes for (1) and (2) in an isolated credential-free master snapshot: the failing cases plus disposal, cleared-target, wrong-response-chat, and live-target controls pass. That candidate passes full flutter analyze, all 3,485 unit/widget tests (1 existing skip), formatting (1,003 files unchanged), eight-locale/generated-assets/registration checks, and explicit false/true/invalid build-flag checks. Nevertheless, the independent end-to-end lazy-scroll regression in (3) still fails even with those repairs. It needs a validated scrolling solution rather than another speculative tweak, so I have not committed, pushed, or merged this candidate. This review is not approval of the unmodified head. Left open for revision.

[iebb]

[P1] Match the complete reply target before applying this delayed quote. If the latest reference now replies to another chat with the same message ID, the old response still overwrites it; restriction-marked refreshes need guarding too.

[iebb]

[P2] Preserve discussion rows whose numeric ID equals the channel post ID. The preceding ID-only root filter drops (-2002,42) when the source post is (-1001,42), before this composite lookup can run.

[iebb]

[P2] A proportional offset is not the parent row's position with variable-height messages. A 100-comment real-sheet fixture with long first rows leaves parent 50 off-screen after tapping its quote from comment 100. The key is also read once before lazy materialization; three repeated guesses do not establish a successful jump.

[TiaraBasori]

Fixed in 42716276.

1. Delayed getMessages applies only to the complete current target (P1). The reply-quote resolver now re-validates the full effective identity before writing: the reply's live (replyToChatId ?? chatId, replyToMessageId) pair must still match the request, the current message must not be restriction-redacted, and the returned quote's own chat must match the expected target. The reviewer's case — hold chat A/42, retarget the reply to chat B/42, then complete A — drops the stale response instead of writing A's plaintext onto the B reply; a restriction-marked refresh can no longer be rehydrated from cache.

2. Sheet root filtering uses composite identity (P2). Rows are no longer removed by message.id == widget.message.id alone; the root filter and the by-id cache key by (chatId, messageId). A faith ful sheet fixture with channel root (-1001, 42) and discussion comment (-2002, 42) keeps the comment row.

3. In-sheet lazy jump reaches the parent (P2). _scrollToSheetReply no longer guesses a proportional offset three times and no longer reads _rowKeys[targetId] before a lazy target can acquire its key. It walks the list with a bounded, verified search: scroll, pump, and check whether the target row is actually materialized and on screen, adjusting by the measured position it observes; a jump only reports success when the target row is materialized and visible, otherwise it falls back to an explicit verified navigation. The reviewer's 100-comment / variable-height fixture (comment 100 replying to comment 50, rows 1–10 with 100 lines each) now materializes parent 50.

Coverage added in test/message_replies_sheet_test.dart: the held-response retarget and restriction cases, the colliding discussion-comment id case, and the variable-height off-screen jump. Existing reply/merge/Moments suites stay green (chat_reply_resolution_test 3/3, chat_scroll_metrics_test 26/26, moments_comment_reaction_test 4/4).

Gates at 42716276 (CI SDK 3.44.2): format clean on changed files, flutter analyze no issues, message_replies_sheet_test 17/17, l10n check + gen_assets --check + check_l10n_strings all pass.

[iebb]

Re-reviewed 4271627 against origin/master 4e34da3 and reran the earlier reproductions. The complete reply identity/restriction/disposal guards and composite root filtering now pass: retargeted/cleared/restricted/disposed replies, wrong-chat responses, unchanged-target control, and cross-chat numeric-ID collisions. Thank you for addressing those.

The variable-height lazy-list blocker remains. The exact independent test from the prior review still fails on the new implementation: 100 comments, first ten each 100 text lines, comment 100 replying to comment 50; jump to the real ListView's bottom, verify 50 is unmaterialized, tap messageReplyOpenOriginal, pumpAndSettle, expect the parent row. Actual: zero matching parent rows. Running the supplied message_replies_sheet suite plus independent async/identity/collision/scroll cases gives 27 pass / 1 fail; the PR's new shorter scroll fixture passes but does not cover this distribution.

_scrollToSheetReply returns void on both success and exhaustion, while _openReplyTarget always returns after awaiting it. Consequently there is no verified navigation fallback despite the new comment's claim. This needs a production-widget regression with strongly non-uniform heights, with target visibility (not just an offset change) asserted.

Terms classification remains compliant/unchanged: normal reply presentation/navigation, with redaction guards inspected. Current Quality is green, but the confirmed navigation failure blocks merging; leaving the useful PR open for revision.

[iebb]

[P1] A failed measured/probe scroll is still treated as successful navigation. The unchanged independent production-widget reproduction still fails on this head: load 100 discussion comments, make comments 1–10 each 100 lines, scroll to comment 100 which replies to loaded comment 50, then tap its actual reply anchor. After settling, comment 50 is still not materialized. The five probes plus ten upward half-viewport steps can exhaust or reach the wrong range, and this unconditional return prevents any explicit navigation fallback. Please make the actual target visible reliably, or report scroll failure and use a verified correctly addressed fallback rather than silently swallowing the tap.

[TiaraBasori]

Fixed in 599bb7f6.

The in-sheet jump is now a measured sweep, not an estimated one (P1). The old descent guessed a probe offset in the remaining pixel range and read the top row index back; with ten 100-line comments in front of the target it kept the wrong half of the range and ran out of its five-step budget, and on exhaustion it returned silently.

It now decides every step from the window the sliver has actually built — the target's item index is compared against the inclusive range of materialized rows: target materialized → jump to its measured reveal offset and verify; target above the built range → step up by 0.8 viewport; below → step down by 0.8 viewport. Scroll offset is monotone in item index, so each step moves strictly toward the target and the sweep terminates (budget 240 frames, well beyond the ~64 steps the reviewer's 45,000 px distribution needs). Nothing is proportional, nothing is estimated, and success means the target row is materialized AND intersects the viewport — never that some offset changed.

A failed jump is no longer swallowed. _scrollToSheetReply returns Future<bool> (verified visibility). _openReplyTarget now, on failure, falls through to the existing explicit navigation for the same (chatId, messageId): onViewInChat(MessageRepliesViewTarget(chatId, messageId, title)) (cross-chat target) or onOpenReply(messageId) (same chat) — always the full addressed pair, never an id-only guess.

Coverage added:

• the in-sheet jump reaches a parent under phone-width strongly non-uniform rows — your exact distribution at a 390×844 phone viewport: 100 comments, comments 1–10 each 100 lines of long wrapping text (~4,000 px per tall row), comment 100 replying to comment 50; scroll to the bottom, assert comment 50 unmaterialized, tap messageReplyOpenOriginal, then assert the row is materialized and its rect intersects the sheet viewport. Red on the previous head: Found 0 widgets with key [<'messageRepliesSheetMessage-40050'>]: []. Green now.
• a failed in-sheet jump falls back to verified in-chat navigation — with scrolling forced to fail, tapping the quote anchor must produce exactly one onViewInChat(chatId: -2002, messageId: <target>) and no id-only onOpenReply.

Gates at 599bb7f6 (CI SDK 3.44.2): format 0 changed, flutter analyze no issues at all severities, message_replies_sheet_test 19/19 (17 existing + 2 new), chat_reply_resolution_test 3/3, chat_scroll_metrics_test 26/26, moments_comment_reaction_test 4/4, l10n three-check + registration anchors all pass, no debug instrumentation left.

[iebb]

Re-reviewed the updated implementation and reran the earlier lazy-row, colliding chat/message ID, and asynchronous hydration reproductions. The long/nonuniform lazy-list jump now succeeds only when the exact target is actually visible, with an explicit correctly paired navigation fallback on failure. Quote redaction, retargeting, clear/dispose, cross-chat identity, and account-scoped Moments metadata cases remain correct (37 focused checks on this PR). Earlier change requests are resolved for this head.

Independent reviewer confirmation: the completed checklist and implementation classify as compliant/unchanged (ordinary explicit navigation/read-only search and reply resolution), not a Section 1.4 exception. Applicable exact-head Quality CI is green. Credential-free snapshots use secrets_example.dart; no account/session data or release/deployment workflow was used.

The exact combined master candidate 85b2c85 (tree 0511cdb9874d31a197d3eb858a73d6d3c9c43519) passes 3,610 unit/widget tests (1 existing skip), 115 focused tests, 13 independent boundary/reproduction tests, full analysis, repository formatting (1,024 Dart files unchanged), 8-locale validation/generated assets, registration anchors, and guarded-feature variants (false:14; invalid:14; true:116) plus the enabled feature-interaction check. No native/platform implementation changed; platform paths were exercised by the focused widget fixtures.