Fix unread counter stuck after reading all articles

markRead() fired its PUT fire-and-forget with no retry and silently
swallowed failures. If one PUT among a burst (paging through article
view fires one per page turn) failed or lost a race with the app's own
background sync()->fetchData() refetch, that article's read-mark was
permanently lost: the header's unreadCount (derived live from
allItems) would show it again mid-session, and a reload reproduced it
identically since the DB genuinely still had it unread.

- markRead() now retries transient failures (no response / 5xx / 429)
  with backoff and a request timeout, skips retrying non-retryable
  4xx, and surfaces a message on final failure instead of only
  console.log.
- A pendingReadCounts refcount (keyed by article id) tracks in-flight/
  retrying marks; fetchData() excludes those ids - snapshotting before
  its GET is dispatched, not just once the response lands - so a
  concurrent refetch can't resurrect an article whose read-confirmation
  is still in flight or unsettled at request time.
- markAllRead() now reports a partial-failure summary instead of
  unconditionally claiming full success when some marks fail.

Extends vue/src/composables/__tests__/useFeeds.spec.js with coverage
for retry/backoff, non-retryable errors, the dispatch-before-response
race, overlapping concurrent marks for the same id, and markAllRead's
partial-failure message.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVw1XNQjodp4B7qiZqjtDE

vue/src/composables/useFeeds.js

@@ -228,12 +228,74 @@ async function getReadable(feed, index) {
   }
 }
 
+// Ids with a mark-read PUT in flight (or being retried) — see markRead() and
+// fetchData() below. A refcount rather than a plain Set: nextArticle()/
+// prevArticle() can both re-mark the same article (page forward, back,
+// forward again), so two overlapping markRead() calls for one id must both
+// finish before fetchData() is allowed to trust the server's word on it —
+// otherwise the first call to settle would clear the id out from under the
+// second, still-in-flight one.
+const pendingReadCounts = new Map()
+
+function addPendingRead(id) {
+  pendingReadCounts.set(id, (pendingReadCounts.get(id) ?? 0) + 1)
+}
+
+function removePendingRead(id) {
+  const count = pendingReadCounts.get(id) ?? 0
+  if (count <= 1) {
+    pendingReadCounts.delete(id)
+  } else {
+    pendingReadCounts.set(id, count - 1)
+  }
+}
+
+function delay(ms) {
+  return new Promise(resolve => setTimeout(resolve, ms))
+}
+
+// Short backoff between retries of a failed mark-read PUT — each entry is the
+// wait before that retry attempt.
+const MARK_READ_RETRY_DELAYS_MS = [300, 1000]
+// Bounds how long a hung request (dead connection, captive portal — axios has
+// no default timeout) can keep an id "pending": without this, a request that
+// never settles would never leave pendingReadCounts, silently withholding
+// that article from every fetchData() for the rest of the session.
+const MARK_READ_TIMEOUT_MS = 10000
+
+// 4xx responses (expired token, item not found/not owned — see
+// src/reader/mark_read.rs) mean the request itself is wrong and won't
+// succeed on retry; only a missing response (network error, timeout) or a
+// server-side/rate-limit status is worth retrying.
+function isRetryableMarkReadError(error) {
+  const status = error.response?.status
+  return status === undefined || status >= 500 || status === 429
+}
+
+// Resolves to true once the article is confirmed read server-side, or false
+// once retries (if any) are exhausted / the error isn't retryable.
 async function markRead(id) {
+  addPendingRead(id)
   try {
-    const response = await axios.put("/api/v1/article/read/" + id, null, authHeaders())
-    console.log(response.status)
-  } catch (error) {
-    console.log(error)
+    for (let attempt = 0; ; attempt++) {
+      try {
+        await axios.put("/api/v1/article/read/" + id, null, { ...authHeaders(), timeout: MARK_READ_TIMEOUT_MS })
+        return true
+      } catch (error) {
+        console.error('Error marking article read:', error)
+        if (attempt >= MARK_READ_RETRY_DELAYS_MS.length || !isRetryableMarkReadError(error)) {
+          // Out of retries, or a retry can't help — this mark never committed
+          // server-side, so the item genuinely is still unread there. Surface
+          // it rather than letting it silently vanish from the local list now
+          // only to mysteriously reappear as unread later.
+          showMessageForXSeconds('Could not mark an article as read. It may reappear as unread.', 5)
+          return false
+        }
+        await delay(MARK_READ_RETRY_DELAYS_MS[attempt])
+      }
+    }
+  } finally {
+    removePendingRead(id)
   }
 }
 
@@ -265,15 +327,28 @@ async function setFeedFilter(title) {
 const fetchData = async () => {
   const user_id = localStorage.getItem("user-id")
   try {
+    // Snapshot ids pending *before* the GET goes out, not just when its
+    // response comes back. A markRead() PUT that commits while this GET is
+    // in flight is invisible to the check below (its id has already been
+    // cleared by the time the response arrives) even though the server read
+    // the DB before that commit and so still reported the item unread — this
+    // snapshot catches that case too.
+    const pendingBeforeFetch = new Set(pendingReadCounts.keys())
     const response = await axios.get("/api/v1/article/get/" + user_id, authHeaders());
     const items = [];
     response.data.feeds.forEach(feed => {
       feed.items.forEach(item => items.push({ ...item, feedTitle: feed.title }));
     });
+    // An item pending at either end of this request may not have committed
+    // server-side yet, so the server can still report it unread here. Drop it
+    // from this snapshot too — otherwise a concurrent background sync's
+    // refetch (see sync()) would resurrect it as unread out from under the
+    // user while markRead() is still confirming or retrying it.
+    const freshItems = items.filter(item => !pendingBeforeFetch.has(item.id) && !pendingReadCounts.has(item.id));
     // timestamps are zero-padded "YYYY-MM-DD HH:MM:SS" strings, so a plain
     // lexicographic comparison sorts them chronologically.
-    items.sort((a, b) => b.timestamp.localeCompare(a.timestamp));
-    allItems.value = items;
+    freshItems.sort((a, b) => b.timestamp.localeCompare(a.timestamp));
+    allItems.value = freshItems;
     applyFilter();
     refreshUnreadDisplay();
     await nextTick();
@@ -411,9 +486,18 @@ async function markAllRead() {
   allItems.value = allItems.value.filter(feed => !readIds.has(feed.id))
   currentIndex.value = 0
   refreshUnreadDisplay()
-  // markRead swallows its own errors, so Promise.all can't reject here.
-  await Promise.all(ids.map(id => markRead(id)))
-  showMessageForXSeconds('All articles marked as read.', 5)
+  // markRead() resolves to true/false rather than rejecting, so Promise.all
+  // can't reject here — but a false means that article is still unread
+  // server-side, which the message below must not contradict.
+  const results = await Promise.all(ids.map(id => markRead(id)))
+  const failedCount = results.filter(ok => !ok).length
+  if (failedCount === 0) {
+    showMessageForXSeconds('All articles marked as read.', 5)
+  } else {
+    // markRead() already surfaced each individual failure — this summarizes
+    // the batch outcome instead of claiming full success over it.
+    showMessageForXSeconds(`Marked ${ids.length - failedCount} of ${ids.length} as read; ${failedCount} failed and may reappear.`, 5)
+  }
 }
 
 function markCurrentArticleRead() {