[Bug]: Deleting a project leaves its Design Browser history and viewport in localStorage

[roian6]

What happened?

On current main, a successful project deletion removes the daemon project and open-design:project-tabs:v1:<projectId>, but leaves two Design Browser records in the browser profile:

• od:design-browser:<projectId>:history:v1
• od:design-browser:<projectId>:viewport:v1

The history record stores complete visited URLs plus titles and visit metadata, so deleted projects can leave stale browsing data in localStorage indefinitely. Failed deletion should continue preserving these records.

Steps to reproduce

1. Open a project and use the Design Browser to visit a URL.
2. Switch the Design Browser viewport to Tablet or Mobile.
3. Confirm the project's history and viewport keys exist in localStorage.
4. Delete the project successfully.
5. Observe that the tab-state key is gone but both od:design-browser:<projectId>:* keys remain.

Expected behavior

After a successful project deletion, that project's Design Browser history and viewport records are removed together with the existing tab-state cache. If the daemon deletion fails, all three records are retained. Cleanup should remain scoped to the deleted project and be safe to repeat.

Version / platform

Current main 517f39acde402c1a7af2189167a8d6957a3dac71 (apps/web package 0.16.1); Linux source-level Vitest reproduction.

Additional context

A focused regression was RED on current main (1 failure, 21 passes) and GREEN with a throwaway minimal cleanup spike (22/22). The probe ran under Node 22 rather than the repository-required Node 24, so broader validation remains outstanding.

No production patch is proposed here yet: draft PR #6142 also edits deleteProject() and introduces workspace-scoped tab cache keys. The final implementation should reuse one owner for the Design Browser key builders and cleanup, and reconcile deletion scope with #6142 rather than race its same hunk.

[lefarcen]

Hi @roian6! 👋

Thanks for narrowing this down to the exact keys and the success-vs-failure behavior. I checked the current web-side delete path, and this looks confirmed: deleteProject() only clears open-design:project-tabs:v1:<projectId> after a successful DELETE, while the Design Browser history and viewport are persisted under separate od:design-browser:<projectId>:* keys with no matching cleanup on project removal.

So we should treat this as a real bug, not just stale test state. The expected behavior you described also matches the current control flow: successful deletion should prune all three per-project browser caches, and a failed deletion should keep them intact. Since draft PR #6142 is already touching deleteProject() and the project-tab key shape, we should reconcile the final cleanup there (or immediately on top of it) so we do not race the same hunk from two directions.

Appreciate the focused repro and the note about the missing shared owner for these key builders — that is the right seam to clean up here.

[nmsn]

/claim

[lefarcen]

Hey @nmsn, thanks for picking this up! The repro here is nicely scoped.

How long do you think it'll take — a few hours, 1–3 days, around a week, or longer?

[nmsn]

a few hours

[lefarcen]

PR #6354 is up for this now.

It takes the scoped path discussed here: after a successful delete, it clears the existing per-project tabs cache plus the two Design Browser localStorage keys (history and viewport), while still keeping all three keys intact when the delete request fails.

Keeping this issue open until the PR lands.