fix: show same-path re-uploads without a manual refresh

[alukach]

Problem

Re-uploading a file to the exact same path in the object browser, without navigating away, stayed hidden until you navigated or refreshed the page.

Root cause

• The object listing is fetched server-side once at page render and passed to DirectoryList as a static objects prop — nothing re-fetches it after an upload.
• mergeUploadsWithFiles keys rows by filename. A re-upload to an existing path finds the existing server row and just spreads uploadProgress onto it, leaving the old size/updated_at/object in place. When it flips to completed the row looks identical to before — no new row, no changed metadata — so the re-upload is invisible.
• Unlike the profile-image flow (a server action that calls revalidatePath), product uploads go client→S3 directly, so nothing invalidates the listing.

Fix

Edge-trigger router.refresh() in DirectoryList when this product scope's uploads drain (last uploading/queued → none). That re-runs the server component and re-lists S3 — the programmatic equivalent of the manual navigate/refresh that already worked. A same-path re-upload now updates its size/date/etag in place.

router.refresh() rather than revalidatePath because product uploads have no server action to hang revalidation on.

Not covered (separate layer)

File content URLs (fileSourceUrl, the external image-viewer iframe) are keyed by path only, so a re-uploaded image's bytes can still render from browser/CDN cache even after the listing updates. Fixing that means adding a ?v={etag|updated_at} cache-buster across file URLs + previews — left out of this PR.

Testing

• tsc --noEmit passes clean.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
source-cooperative	Ready	Preview, Comment	Jul 1, 2026 6:09am

[claude]

Claude finished @alukach's task in 2m 31s —— View job

---

Reviewing PR #409

• Gather context (diff, changed files)
• Read DirectoryList.tsx and Dropzone.tsx changes in full
• Analyze correctness, security, best-practice issues
• Post final review

---

✅ No blocking issues — safe to merge.

Traced both fixes end-to-end against UploadProvider/upload-queue-manager.ts (to confirm upload.key semantics) and DirectoryRow.tsx (to confirm onDeleted fires with item.path only after the delete call resolves). Both mechanisms check out:

• src/components/features/uploader/Dropzone.tsx:37-44 — the wasActive ref edge-triggers correctly: on mount or remount it just resyncs to current state (no spurious refresh), and only fires router.refresh() on the true → false transition of hasActiveUploads. Since Dropzone is mounted once in the persistent product layout (layout.tsx:92), the ref survives prefix navigation as intended.
• src/components/features/products/object-browser/DirectoryList.tsx:58-70 — clearing deletedPaths keyed off scopedUploads keys is consistent with how mergeUploadsWithFiles sets path = upload.key for files uploaded directly into the current directory (utils.ts:60-73), so the un-hide correctly targets the same key space used for hiding.

Two non-blocking observations, already effectively acknowledged by the PR's scoping:

• DirectoryList.tsx:63-70: the un-hide only matches on exact upload.key. If a directory was deleted (DirectoryRow.tsx:93,98 calls onDeleted(item.path) with the directory's placeholder path, e.g. "foo/") and the user then re-uploads files nested under that directory, the nested upload keys (e.g. "foo/bar.txt") never match the stored directory path, so the directory stays hidden until navigate/refresh. Same class of edge case as the file-content-caching gap the PR already calls out as "not covered" — worth a follow-up if it comes up in practice, not blocking here since the PR is explicitly scoped to same-path file re-uploads.
• Dropzone.tsx:37-39: getUploadsForScope(scope) is called unmemoized on every render to derive hasActiveUploads; harmless given the cheap array scan and existing codebase patterns, just noting it's slightly more work than necessary.