fix(user-flow): close offline-queue, export, session, ban & realtime gaps
Some checks failed
E2E / Playwright E2E (chromium-desktop) (push) Failing after 6m52s
E2E / Cross-UA smoke matrix (push) Failing after 3m50s

Comprehensive user-flow review across guest/host/admin roles, then fixes with
e2e regression guards. Highlights:

- Offline upload queue auto-resumes on reconnect: network errors keep items
  pending (not error), 4xx are terminal (no infinite retry), quota exhaustion
  returns a distinct 413; queue cap + dedup.
- Export lifecycle: release atomically locks uploads; reopen invalidates and
  re-release regenerates the keepsake; workers claim their job atomically so a
  reopen->re-release can't corrupt the ZIP; startup re-spawns interrupted
  exports.
- Sessions slide on activity (no 30-day cliff); JWT expiry deferred to the
  revocable session row; sign-out-everywhere + revoke-on-PIN-reset.
- Ban always hides content (v_feed / find_visible_media / export filter
  is_banned) but stays a read-only ban per USER_JOURNEYS §10 — sessions are
  not revoked, read access + keepsake download preserved.
- Realtime: server-clock SSE delta cursor; event-closed/opened drive the UI
  live; feed_delta rate-limited; like returns {liked, like_count} to fix
  multi-device drift; lightbox live comments; diashow delta backfill.
- Forgotten-PIN in-app request flow; simultaneous same-name join returns 409;
  quota increment is transactional; operator floor.

Adds e2e/specs/10-flow-review/ (offline resume, export integrity, deterministic
anti-race guard) and updates existing specs for the new contracts.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
MechaCat02
2026-07-10 23:05:37 +02:00
parent 16d1f356be
commit 641174717c
38 changed files with 1400 additions and 153 deletions

View File

@@ -389,18 +389,24 @@
async function handleLike(id: string) {
try {
await api.post(`/upload/${id}/like`);
// Set state from the server's authoritative response rather than blind-inverting
// local state. On a second device (same recovered user), the `like-update`
// broadcast only carries `like_count` — so a blind invert would drift
// `liked_by_me` until refresh. The response gives both, exactly.
const res = await api.post<{ liked: boolean; like_count: number | null }>(`/upload/${id}/like`);
vibrate(10);
// like_count is null when the server's count query hiccuped — keep the current
// count in that case rather than adopting a wrong number.
uploads = uploads.map((u) =>
u.id === id
? { ...u, liked_by_me: !u.liked_by_me, like_count: u.liked_by_me ? u.like_count - 1 : u.like_count + 1 }
? { ...u, liked_by_me: res.liked, like_count: res.like_count ?? u.like_count }
: u
);
if (selectedUpload?.id === id) {
selectedUpload = {
...selectedUpload,
liked_by_me: !selectedUpload.liked_by_me,
like_count: selectedUpload.liked_by_me ? selectedUpload.like_count - 1 : selectedUpload.like_count + 1,
liked_by_me: res.liked,
like_count: res.like_count ?? selectedUpload.like_count,
};
}
} catch (e) {