评论中显示的其他评论备注

Dannii · 2026 年11 月 5 日 06:57

当从通知列表中的某条帖子评论切换到另一条时，显示的评论备注属于其他评论。刷新页面后才会显示正确的备注。

我的 Discourse 版本：2026.7.4。

pmusaraj · 2026 年11 月 5 日 21:08

您能在最新版本的 Discourse 或至少是最近一个月的版本中复现该问题吗？

Dannii · 2026 年11 月 5 日 23:12

我使用的是 LTS 版本，因此我不会仅仅为了测试此功能而升级到非 LTS 版本。

这看起来像是一个新的错误。2026.7.4 版本中是否对审核队列进行了任何更改？

Dannii · 2026 年11 月 5 日 23:33

看起来这大概修复了该 bug。

FIX: Stop reviewable state from leaking to the next reviewable (#42744)

main ← reviewable-stale-state-between-items

ZogStriP

04:55PM - 21 Aug 26 UTC

+427 -221

Moving from one reviewable to another — by clicking through the review queue lis…t in the user menu, for example — is a change of model on the same route, so the whole `ReviewableItem` tree is re-rendered in place rather than torn down. Any state those components hold for a single reviewable therefore survives the transition. `ReviewableTimeline` copied `reviewable_notes` into a tracked field in its constructor, which as a result only ever ran for the first reviewable rendered. A note added to one reviewable was then shown on every reviewable visited afterwards, and a reviewable's own note was missing whenever it wasn't the first one opened. Notes are now read from, and written to, the reviewable itself. `ReviewableItem` kept `editing` and its pending `_updates` as well, so leaving a reviewable mid-edit landed on the next one still in edit mode, and saving from there wrote the previous reviewable's changes to it. --- ### Reproducing 1. Flag a few posts so the review queue has several pending items. 2. As a moderator, open the user menu, go to the review queue tab, and click one of the items. 3. Add a note. 4. Open the user menu again and click a different item. The note from the first item is shown on the second. Doing it in the other order — opening a reviewable with no notes first — hides the note on the reviewable that actually owns it. The review queue list itself has always been correct, because it renders each reviewable in an `{{#each}}` and so gives each one its own components. For the edit half, do the same with two queued posts and click "Edit Post" before navigating away. ### `ReviewableItem` becomes a glimmer component `didUpdateAttrs` was the only place this state could be reset, and it is classic-component-only. The state belonging to a single reviewable now lives in a `@cached` `state` getter that reads `this.args.reviewable`, so a different reviewable produces a fresh `trackedObject` and nothing carries over — the reset is a consequence of the argument changing rather than a hook that has to remember every field. The `@computed` getters become plain getters, `this.set` gives way to assignment, and `{{mut}}` on `claimed_by` gives way to a callback. Plain getters only track what the model declares, so `Reviewable` now declares its server payload as `@tracked`, the way `Post` already does. `reviewable_notes` is an `@autoTrackedArray` seeded to `[]`, which is what lets the timeline append to it directly instead of bridging through `get`/`set` from `@ember/object`. ### Test coverage None of this reproduces on a full page load, so `visit_reviewable` — how every reviewable system spec navigates — cannot exercise it. The review page object grows a `visit_reviewable_from_user_menu` that stays within the running app. `shows correct IP when navigating between reviewables` now uses it. Worth flagging: that spec was added alongside the `didUpdateAttrs` fix it was written for, and because it navigated with `visit_reviewable` it had been passing either way ever since. It only becomes a real guard here. The component tests swap a tracked `@reviewable` on a mounted component, which is the mechanism at fault. Each one kills a specific mutation — removing the argument read from `state()`, or dropping `@autoTrackedArray` — except `keeps a pending edit when the reviewable it belongs to is refreshed`, which is deliberately the other direction: `store.find` updates a record in place after every `perform`, so it guards against a cache key that invalidates too eagerly. `removes a deleted note from the timeline` covers a path that had no test in either suite. ### Notes `updating` and `disabled` are deliberately left outside `state`. They belong to an in-flight `perform()` request whose `.finally()` clears them — resetting them on navigation would clear the flag out from under a request started on the new reviewable. The bare `this.args.reviewable;` in `state()` is what ties the cache to a single reviewable; deleting it makes both reset tests fail. `no-unused-expressions` only runs on `.ts`/`.gts` here, so unlike the equivalent in `block-outlet-root-container.gts` nothing catches it, hence the comment.

能否将其回移（backport）到 2026.7.4 版本？

pmusaraj · 2026 年11 月 6 日 16:55

没错，你说得对。我已经将该修复补丁回迁到 2026.7 版本，请重新构建并告知我它是否解决了你的问题。

话题		回复	浏览量
Review of review queue seems to show duplicated post bodies Bug review-queue	3	597	2023 年9 月 29 日
Spurious notification when navigating away from review queue after adding note Bug review-queue , fixed	2	204	2025 年11 月 18 日
A new review queue layout with all new features Announcements review-queue	43	3384	2026 年9 月 20 日
Discourse 2.3.0.beta7 Release Notes Announcements release-notes	1	2939	2019 年4 月 5 日
Review Queue Pagination/Infinite Scrolling after Taking an Action Bug	6	983	2022 年3 月 31 日

评论中显示的其他评论备注

相关话题