Skip to content

fix(web): make the finished-processing refresh effect actually fire#1188

Open
abhay-codes07 wants to merge 1 commit into
supermemoryai:mainfrom
abhay-codes07:fix/processing-documents-refresh-effect
Open

fix(web): make the finished-processing refresh effect actually fire#1188
abhay-codes07 wants to merge 1 commit into
supermemoryai:mainfrom
abhay-codes07:fix/processing-documents-refresh-effect

Conversation

@abhay-codes07

@abhay-codes07 abhay-codes07 commented Jul 2, 2026

Copy link
Copy Markdown

What

The useProcessingDocuments effect that's supposed to refetch documents-with-memories and dashboard-recents when a document finishes processing never fires. Its dependency array is

}, [processingMap.keys, queryClient.refetchQueries])

processingMap.keys (uncalled) is Map.prototype.keys — the same function object for every Map instance — and queryClient.refetchQueries is likewise a stable method reference. Both deps are constant across renders, so the effect runs exactly once on mount, when the previous and current id sets are both empty. The prev/current diff that detects "these docs just finished" never re-executes, and the delayed refresh the comment describes is dead code. The eslint-disable-next-line react-hooks/exhaustive-deps on the array is what kept the lint rule from flagging it.

Effect for users: after adding a document, the memories grid and dashboard recents don't pick up the extracted memories when processing completes — the card stays stale until something else happens to refetch.

How

Two changes, both needed:

  1. The effect now depends on [processingMap, queryClient].
  2. docs is memoized on data so processingMap only changes identity when the poll payload actually changes. React Query's structural sharing keeps data referentially stable between identical polls, so this holds. Without this second change the map would get a fresh identity every render, and each effect re-run's cleanup could cancel the pending 1s/4s refresh timers before they fire — trading "never refreshes" for "sometimes loses the refresh".

With both in place: a doc disappearing from the processing poll → new data → new processingMap → effect re-runs → diff catches the finished id → delayed refetches fire. Renders caused by anything else don't re-run the effect, so the timers survive.

Both stray eslint-disable comments are removed — the dependency arrays are now honest.

Testing

  • biome check clean; no tsc errors in the touched file (the web app has pre-existing errors elsewhere and ignoreBuildErrors in its Next config — none involve this file).
  • The web app has no React hook test harness, so this is verified by analysis rather than a unit test: the bug itself is a JavaScript identity fact (new Map().keys === new Map().keystrue), and the structural-sharing guarantee that makes the fix safe is React Query's documented default. Happy to add a hook test if you'd like a @testing-library/react setup introduced for it.

cc @MaheshtheDev


Session Details

  • Session: View Session
  • Requested by: Unknown
  • Address comments on this PR. Add (aside) to your comment to have me ignore it.

The effect in useProcessingDocuments that refetches document lists
when a document finishes processing depended on
[processingMap.keys, queryClient.refetchQueries]. Both are prototype
methods - Map.prototype.keys is the same function object for every
Map instance - so the dependencies never changed, the effect ran
exactly once on mount (when both the previous and current id sets are
empty), and the delayed documents-with-memories / dashboard-recents
refetch never happened. The eslint-disable on the dependency array
hid the lint error that would have caught this.

Depend on processingMap itself, and memoize docs on data so the map's
identity only changes when the poll payload changes (React Query's
structural sharing keeps data referentially stable between identical
polls). Without that, the map would get a new identity every render
and each re-run's cleanup could cancel the pending 1s/4s refresh
timers before they fire.
Copilot AI review requested due to automatic review settings July 2, 2026 03:25

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@vorflux vorflux Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary

Reviewed — found 1 issue(s). I reviewed the change to apps/web/hooks/use-processing-documents.ts, which is intended to make the finished-processing refresh effect re-run when the processing map changes. The new dependency fixes the previous inert dependency, but it also makes the effect cleanup cancel pending delayed refreshes on subsequent processing-list changes.

Findings

apps/web/hooks/use-processing-documents.ts

  1. The effect cleanup can cancel the delayed refresh timers for a document that just finished when processingMap changes again before those timers fire.

Verdict

⚠️ Changes requested. The delayed refresh is still race-prone when the processing list changes again shortly after a document finishes, so the finished document can remain stale.


Review with Vorflux

// `processingMap` (not `processingMap.keys` — that's the shared
// Map.prototype method, identical for every map, so the effect would
// never re-run and finished docs would never trigger a refresh).
}, [processingMap, queryClient])

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This cleanup now runs every time processingMap changes, so a later poll can cancel the delayed refetches that were scheduled for a document that just finished. For example, if document A disappears and the hook schedules the 1s/4s refreshes, then another upload or sync changes the processing list before those timers fire, React runs this cleanup and clears both timers. Consider tracking pending timer IDs in a ref and clearing them only on unmount, or otherwise avoid canceling finished-document refreshes on unrelated processingMap changes.

@vorflux

vorflux Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Testing

The testing subagent verified the useProcessingDocuments behavior with a focused hook harness and through the actual MemoriesGrid consuming surface in the running Next.js app. The transition from processing to finished refreshed the downstream memories surfaces as intended.

Commands run:

node /tmp/test-processing-documents-effect.mjs
bunx biome ci apps/web/hooks/use-processing-documents.ts
cd apps/web && bunx tsc --noEmit --pretty false --skipLibCheck
cd apps/web
bun run dev:app -- --hostname 0.0.0.0

Result:

PASS processing-documents effect harness: transition refreshes fire, unchanged polling does not, old dependency reproduces missed refresh

biome ci apps/web/hooks/use-processing-documents.ts: passed

TypeScript audit failed with broad existing app/workspace diagnostics, but no diagnostics referenced apps/web/hooks/use-processing-documents.ts.

Browser verification: initial grid state showed PR 1188 processing refresh fixture with visible Thinking / processing badge. After the processing poll returned empty and the hook timers fired, the same grid refreshed to PR 1188 finished refresh fixture and the processing badge disappeared.

Verdict

Passed. The tested behavior works in the focused harness and in the running app surface; the TypeScript audit reported only unrelated existing diagnostics.


Attached Images and Videos

pr-1188-grid-early-processing.png

pr-1188-grid-early-finished.png

🎥 View recording: pr-1188-memories-grid-transition-early.webm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants