fix folder deletion not reflected in UI

[krushnarout]

The proxy was setting Cache-Control: max-age=60, stale-while-revalidate=300 on folder GET responses. After deletion, the browser served the cached list — making the deleted folder reappear. Removed the HTTP cache since the app already manages its own JS-level cache.

Demo

Screen.Recording.2026-03-10.at.9.19.10.PM.mov

[greptile-apps]

Greptile Summary

This PR fixes a UI bug where deleted folders would reappear after deletion by removing the HTTP Cache-Control: private, max-age=60, stale-while-revalidate=300 header that was being applied to all GET /folders proxy responses.

• Root cause: The Next.js API proxy route was instructing browsers to cache folder list responses for 60 seconds (with an additional 300-second stale-while-revalidate window). After a folder was deleted, the subsequent GET /folders request was served from the browser cache, making the deleted folder reappear.
• Fix: The three lines setting the folder-specific cache header are removed. Only truly static reference data (app-categories, app-capabilities, app/plans) retains HTTP caching.
• Suggestion: While the fix is correct, an explicit Cache-Control: no-store header for all non-static endpoints would be more defensive and communicate intent clearly to any future CDN or intermediate proxy.

Confidence Score: 5/5

• This PR is safe to merge — it removes a small, well-scoped cache header that was causing a clear UI bug.
• The change is a 3-line deletion with a narrow, well-understood impact. Static reference endpoints remain cached as before; only the folder-list caching is removed. No logic, authentication, or data flow is altered. The remaining code is unchanged and the fix directly addresses the described bug.
• No files require special attention.

Important Files Changed

Filename	Overview
web/app/src/app/api/proxy/[...path]/route.ts	Removes the Cache-Control: private, max-age=60, stale-while-revalidate=300 header that was being set on folder GET responses, preventing stale cached data from re-appearing in the UI after folder deletion.

Sequence Diagram

sequenceDiagram
    participant Browser
    participant NextProxy as Next.js Proxy<br/>(route.ts)
    participant API as api.omi.me

    Note over Browser,API: BEFORE (with stale cache bug)
    Browser->>NextProxy: GET /api/proxy/folders
    NextProxy->>API: GET /folders
    API-->>NextProxy: 200 OK (folder list)
    NextProxy-->>Browser: 200 OK + Cache-Control: private, max-age=60
    Note over Browser: Browser caches response for 60s

    Browser->>NextProxy: DELETE /api/proxy/folders/:id
    NextProxy->>API: DELETE /folders/:id
    API-->>NextProxy: 204 No Content
    NextProxy-->>Browser: 204 No Content

    Browser->>NextProxy: GET /api/proxy/folders
    Note over Browser: Cache still valid — served from browser cache!
    NextProxy--xBrowser: (request never sent to proxy)
    Note over Browser: Deleted folder reappears in UI 😱

    Note over Browser,API: AFTER (fix applied)
    Browser->>NextProxy: GET /api/proxy/folders
    NextProxy->>API: GET /folders
    API-->>NextProxy: 200 OK (folder list)
    NextProxy-->>Browser: 200 OK (no Cache-Control)
    Note over Browser: No caching — always fetches fresh data

    Browser->>NextProxy: DELETE /api/proxy/folders/:id
    NextProxy->>API: DELETE /folders/:id
    API-->>NextProxy: 204 No Content
    NextProxy-->>Browser: 204 No Content

    Browser->>NextProxy: GET /api/proxy/folders
    NextProxy->>API: GET /folders
    API-->>NextProxy: 200 OK (updated folder list)
    NextProxy-->>Browser: 200 OK ✅

Loading

Comments Outside Diff (1)

1. web/app/src/app/api/proxy/[...path]/route.ts, line 136-145 (link)

   Consider adding explicit no-store for mutable endpoints

   Omitting Cache-Control for folder responses relies on implicit HTTP caching behaviour (authenticated responses are typically not cached). To be defensive and clearly communicate the intent to any intermediate proxy or CDN, consider adding an explicit Cache-Control: no-store for all non-static endpoints instead:

   const cacheHeaders: HeadersInit = {};
   if (
     path.includes('app-categories') ||
     path.includes('app-capabilities') ||
     path.includes('app/plans')
   ) {
     // Static reference data - cache for 1 hour
     cacheHeaders['Cache-Control'] = 'public, max-age=3600, stale-while-revalidate=86400';
   } else {
     // Mutable user data - never cache
     cacheHeaders['Cache-Control'] = 'no-store';
   }

   This makes the no-cache intent explicit for all other endpoints (folders, memories, etc.) and guards against future proxies or CDN deployments that might otherwise cache these responses based on heuristics.

_{Last reviewed commit: 743b40e}