diff options
Diffstat (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md')
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md | 61 |
1 files changed, 1 insertions, 60 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md index 2cc3b5c..aa56727 100644 --- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md +++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md @@ -193,7 +193,7 @@ taking that too literally. | 124 | The worker reads the index directory as the mail root | defect | S | **done** 2026-08-20, unreleased. `mailRootOf()` over `NOTMUCH_CONFIG_MAIL_ROOT`, correct under both layouts. Verified by migrating the developer's own index to NVMe the same day: cold start 38.6 s to 0.67 s | -| 125 | A skipped sync leaves the spinner running for ever | defect | S | open, 2026-08-20, **half closed 2026-08-29 by item 174**: a skipped run now writes `state: skipped` to the status file, so the application can see it happened and clears the spinner without clearing the count. What remains is whether `SyncMonitor` should also time out an observation it never saw end, which covers a run that dies without writing anything at all | +| 125 | A skipped sync leaves the spinner running for ever | defect | S | **done 2026-08-29**, unreleased, in two halves and mostly already built. The exit-75 branch in `onSyncFinished()` predates this session: spinner cleared, no error, no log pane, exit prompt handled, with a test. Item 174 added the external half, a `skipped` state the application can see. What was genuinely missing was the RE-ARM: `runAutoSync()` re-arms when it declines to start (item 89), but a run that LAUNCHES and exits 75 lands in `onSyncFinished()`, which armed nothing, so the edit waited for a manual sync or the next cron tick. Section in the closed file | | 126 | A link with `target="_blank"` does nothing when clicked | defect | S | **done** 2026-08-20, unreleased. `createWindow()` returns a relay page that receives the navigation, hands the URL to the browser and refuses. The URL cannot be read in `createWindow()` itself, which is why a relay rather than a lookup | | 127 | A link's context menu offers four browser actions that cannot work | defect | XS | **done** 2026-08-20, unreleased. Three Open-in actions removed, `CopyLinkToClipboard` kept. Item 126 made them more dangerous rather than less: with a real `createWindow()` they would have started working | @@ -830,65 +830,6 @@ touch `KeyMap`), and one new build dependency, `pkg_check_modules` line here and **no** `REQUIRES` entry in the SlackBuild, which lists only non-stock dependencies. -## 125. A skipped sync leaves the spinner running for ever - -**Observed (user, 2026-08-20):** during the item 124 index migration, a Delete -appeared to do nothing: the view did not refresh, the message did not move, and -restarting the application showed it exactly where it had been. The user then -reported "I see a spinner in the bottom right, is going indefinitely. maybe -that's what stopped the move?" That observation is what identified the cause. - -**Cause (verified from `/proc` and the sync log).** The migration procedure held -`/tmp/mbsync.lock` to keep cron out of the way. qtmaildir auto-syncs a couple of -seconds after a tag action (item 71), so Delete queued its edit and started a -sync; `mailsync.sh` found the lock held and exited **75**, by design: - -``` -2026-08-20T10:00:01+02:00 === SKIPPED: previous run still in progress === -2026-08-20T10:10:01+02:00 === SKIPPED: previous run still in progress === -``` - -75 is `EX_TEMPFAIL`, chosen deliberately so a click landing during a cron run is -not reported as a failure (`assets/mailsync.sh`, the comment at the `flock -n` -guard). The application appears to treat it as neither success nor failure: the -sync indicator never cleared, and because an edit made during a sync is HELD -until the sync ends, the delete sat in that queue waiting for a completion that -could never arrive. `notmuch count tag:deleted` on the account confirmed the -write had not reached the database. - -**Nothing was lost**, and that is worth recording separately: held edits are -written to disk (item 106), so the delete survived and applied as soon as a real -sync ran. The defect is that the user cannot tell. - -**Approach.** Handle exit 75 explicitly wherever `MailSync` reports a finish. -It is a third outcome, not a variant of the other two: the work did not happen, -nothing is wrong, and it should be retried rather than reported. Clearing the -indicator is the minimum; re-arming the auto-sync timer is probably right too, -and item 89 already made a skipped auto-sync re-arm rather than give up, so -there is a precedent to follow rather than a policy to invent. - -**Constraints.** - -- **Do not turn 75 into an error.** The exit code exists precisely so an - overlapping click is not reported as a failed sync, and item 89 settled that a - skip is routine. Showing the log pane here would be a regression. -- **The held-edit queue must still flush.** Whatever clears the indicator has to - leave the queue in a state where the next successful sync sends it, which is - what happened by luck here rather than by design. -- **A stuck indicator is worse than a wrong one**, because it also blocks the - quit prompt's "unsynced changes" story (items 18, 19, 28, 54). This is the - same class of indicator dishonesty those four items each fixed once. - -**Reproducing it.** Hold the lock in one terminal and act in the application: - -```bash -flock /tmp/mbsync.lock -c 'sleep 300' -``` - -Then Delete a message. Verified by hand on 2026-08-20; this is how it was found. - -**Size: S.** - ## 135. The formatting toolbar's buttons stack rather than toggle **Observed (user, 2026-08-21):** pressing Bold a second time on already-bold |