From feb15bcec261501eb49ad0de1fdc05a9992227c2 Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Sat, 29 Aug 2026 10:05:22 +0200 Subject: fix: refresh the conversation dashboard after a write Item 181, from the user's notes: "the thread dashboard doesn't update live with the modifications applied to the list pane. If I mark the thread as read, the dash still reports N unread". ThreadDashboard draws a ThreadDigest, which the worker builds from the index and which reached the pane only when a conversation was selected. A tag write updated the model optimistically and repainted the card beside it, and nothing touched the digest, so the pane went on reporting the unread count, the progress bar and the Waiting-for-you list the conversation had when it was opened. Reachable from the dashboard's own Mark all read button, which is the worst version of it: the number sits directly above the button that fails to move it. refreshDashboardDigest() re-asks the worker for the digest of the conversation on display, and returns at once when the pane is showing anything else. It bumps m_digestGeneration like any other request, so the guards in onThreadDigestLoaded() discard a reply that arrives after the user has moved on. No placeholder digest, unlike the selection path: the pane already holds this conversation, and blanking it to re-fill it would flicker the whole dashboard for a change to one number. Called from onTagsApplied(), where a write is CONFIRMED, and not from the two write funnels. The first attempt put it beside the optimistic model update by analogy with every other optimistic repaint, and that analogy does not hold here: the digest is rebuilt from the index, so a refresh queued beside the write reaches the worker before the write does and answers from the state before it. The test failed identically to no fix at all. Every write rather than a chosen subset, at the user's decision: narrowing it to the writes that change what the dashboard happens to draw today is a list the dashboard can outgrow silently, and this costs a round trip only while a conversation is on screen. Re-requested rather than edited in place, because the digest is a derived summary and recomputing it here would be a second place that has to agree with the worker about what a write did. The test is worker-backed over a real two-message conversation and is driven through the mark_all_read action rather than the private funnel, which is the path the dashboard's own button takes. It asserts the pane carries the unread state before the write, so the assertion after it means something. Suite: 42 of 43, with undoMovesTheMessageBack failing as it does on master (item 136). --- .../2026-08-03-post-0.1.0-usability-closed.md | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md') diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md index 55c5ee7..27b4e28 100644 --- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md +++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md @@ -9315,3 +9315,62 @@ before proceeding. A summary left at the default is a MESSAGE row, so a test meaning to exercise a conversation would quietly exercise the other branch and pass for the wrong reason, which is the fixture trap the top-level document records. + +## 181. The thread dashboard does not follow a write to the conversation it shows + +**Done 2026-08-29**, unreleased, on `thread-row-identity`, from the user's +notes: "the thread dashboard doesn't update live with the modifications applied +to the list pane. If I mark the thread as read, the dash still reports N +unread". + +**Cause, verified in the code.** `ThreadDashboard` draws a `ThreadDigest`, +which the worker builds from the INDEX and which reached the pane in exactly +two places: the selection handler, and `onThreadDigestLoaded()`. A tag write +updated the model optimistically and repainted the card beside it, and nothing +touched the digest, so the pane went on reporting the unread count, the +progress bar and the "Waiting for you" list the conversation had when it was +opened. + +**Reachable from the dashboard's own button.** It carries Mark all read, +Archive and Delete in its bottom strip (item 177), so the user presses Mark all +read and the number directly above it does not move. That is the worst version +of the defect and the one the note reports. + +**Fix.** `MainWindow::refreshDashboardDigest()` re-asks the worker for the +digest of the conversation the pane is showing, and returns at once when the +pane is showing anything else, which is the ordinary case. It bumps +`m_digestGeneration` like any other request, so the three guards in +`onThreadDigestLoaded()` discard a reply that arrives after the user has moved +on. No placeholder digest, unlike the selection path: the pane already holds +this conversation, and blanking it to re-fill it would flicker the whole +dashboard for a change to one number. + +**Called from `onTagsApplied()`, where a write is CONFIRMED, and this is the +part worth keeping.** The first attempt called it from both write funnels, +beside the optimistic model update, by analogy with every other optimistic +repaint. That is wrong here and the test caught it: the digest is rebuilt from +the index, so a refresh queued beside the write reaches the worker BEFORE the +write does and answers from the state before it. The reasoning that made it +look right is the reasoning that applies to a model update, which needs no +round trip; anything read back from the index has to wait for the write to +land. + +**Every write, not a chosen subset.** The user's decision, and the cheaper rule +to keep: narrowing it to the writes that change what the dashboard happens to +draw today is a list the dashboard can outgrow silently, and this costs a round +trip only while a conversation is on screen. It sits beside the unsynced-edits +counter in the same handler for the same reason. + +**Re-requested rather than edited in place.** The digest is a derived summary, +senders and buckets and timestamps and a capped unread list, so updating it +here would be a second place that has to agree with the worker about what a +write did, which is item 180's complaint exactly. + +**Test.** `theDashboardFollowsAWriteToTheConversationItShows`, worker-backed +over a real two-message conversation, driven through the `mark_all_read` ACTION +rather than the private funnel: that is the path the dashboard's own button +takes. It asserts the pane carries the unread state BEFORE the write, so the +assertion after it means something, and mutation-checked by removing the call. +Note the failing runs take 45s and the passing one 295ms: the `QTRY` timeouts +expire when the refresh never comes, which reads as a slow test rather than a +missing feature. -- cgit v1.2.3