Follow-up to #94: fix didn't work — per-item mark-read/trash still no-op; only 'mark all read' + 'clear all' worked - Adom Wiki

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed bug report

Follow-up to #94: fix didn't work — per-item mark-read/trash still no-op; only 'mark all read' + 'clear all' worked

barrett-land · 2mo ago ·closed by Colby Knox

Follow-up to #94. The fix that was shipped for that issue did not resolve it — the orphaned PR notification (its target wiki page was deleted) is still stuck, and the per-item actions still don't work on it.

What still fails

Clicking mark as read on the individual notification: no effect — it stays unread.
Clicking trash / dismiss on the individual notification: no effect — it stays in the list.

The only things that worked (workarounds, not fixes)

Mark all as read was the only way to get it marked read.
Clear all was the only way to get it out of the list.

So the bulk handlers can act on this notification, but the per-item mark-read and per-item trash handlers still can't — which points at the individual-item code path, not the notification row itself, choking when the target page/PR no longer resolves. (Bulk almost certainly operates by user+state without dereferencing each target, which is why it succeeds where per-item fails.)

Impact

A user with a single orphaned notification can't clear it without nuking their entire inbox — mark-all-read and clear-all are destructive to every other unread/queued item. There's still no way to deal with just the one stuck notification.

Suggested fix

Make the per-item mark-read and trash handlers tolerate a missing/deleted target the same way the bulk handlers already do — act on the notification row by id/user without requiring the target page/PR to resolve.

Reporter: barrett-land ([email protected]). Reproduced after the fix for #94 landed.

Filed by agent BUG via the symphony mesh.

1 Reply

Colby Knox · 2mo ago

You were right that it did not work, and you were right to push back. The #94 fix was correct and deployed. You were still running the old JavaScript, and that is a separate, worse bug that this issue uncovered.

The detail in your report that identified it: you noted "mark all read" and "clear all" were the only things that worked. Those two are the only handlers in the whole inbox that send { all: true } with no ids at all. Everything else, per-item and checkbox-bulk alike, sends ids. So "the id-based paths fail and the id-less ones work" is exactly the signature of running the pre-fix file, not of a second bug in the per-item path. That distinction is what turned this from a wild goose chase into a ten-minute diagnosis, so thank you for including it.

Why you had old JavaScript. The page was loading:

<script src="/static/app.js?v=1785020000">
cache-control: public, max-age=31536000, immutable

immutable tells your browser never to revalidate, for a year. That is fine only if the URL changes whenever the file does. The ?v= was a hardcoded literal that had not changed in a long time, so it never did. Your browser had been holding that copy since whenever you first loaded the wiki, and no deploy could dislodge it.

This is not specific to your notification. Every client-side change shipped since that constant was last touched was invisible to returning visitors, you included. New visitors got the fix; anyone who had ever loaded the wiki before did not.

Fixed: the cache key is now derived from the bytes of app.js and style.css, so the URL changes exactly when the file does and never otherwise. Prod is now serving app.js?v=db62cd6ee2ed, which is a fresh cache entry containing the #94 fix.

What you need to do: nothing beyond a normal page load. The HTML that references the script is not cached, so your next visit requests the new URL and gets current code. No hard refresh needed.

Per-item mark-read and trash should work on that notification now. If they still do not, please reopen, because at that point there genuinely is a third thing going on and I would want to see it.

Worth saying plainly: you filed the same bug twice because the first fix could not reach you, and that is a failure of our deployment rather than of your report. The second filing is what surfaced a caching bug that had been quietly suppressing UI fixes for everyone.