Auto-Match should reuse cached batch results when opening rows (avoid redundant Match API calls)

[filiperochalopes]

Related to #2227

User story

As a user, I want candidate results fetched during Auto-Match to be reused when I open individual rows so the system avoids repeating the same expensive Match API calls.

Use case

Run Auto-Match on a Map Project, then open individual rows to review candidates without triggering a new per-row API request for already-fetched data.

Requirements

• After Auto-Match runs, store the batch results client-side keyed by row identifier (e.g., __index or concept UUID).
• When opening a row after Auto-Match, load candidates from the stored batch results instead of calling the Match API again.
• Only call the Match API again when no cached data exists or the user explicitly requests a refresh.
• Prefer a storage approach that survives normal UI state resets (e.g., localStorage, IndexedDB, or another persistent client-side store).

Acceptance criteria

• Given Auto-Match completed, when the user opens a row, then no new Match API call is made if cached results exist for that row.
• Given cached results do not exist for a row, when the user opens it, then the system falls back to calling the Match API.
• Given the user requests a refresh (manual override), then the system re-calls the Match API and updates the stored results.

More details (collapsible)

Context

• Current behavior: Auto-Match triggers a batch call, but opening each row triggers another API call for the same data.
• Impact: unnecessary time/cost, especially when Match API is compute-heavy (~20s/row; AI rerankers/vector search).
• This is an architectural concern raised after closing Redundant API calls when opening rows after Auto-Match in Map Project #2227 as "completed" despite the underlying redundancy concern.

[PratikshaJ-16]

Hi @filiperochalopes , I was working on this area and noticed a related behavior.
In MappingHome.jsx, the API call inside refreshDataByURL() is triggered from componentDidUpdate, and it causes repeated requests depending on component updates.
So, 1. componentDidUpdate runs on every re-render , 2. highlightFromSearch() is executed unconditionally ,3.This can lead to unnecessary updates and API calls. I’m planning to refine the update conditions so that API calls only happen when relevant props change, which should reduce unnecessary requests and stabilize rendering. If this approach aligns with the intended behavior here, I’d be happy to open a PR with the fix .

[PratikshaJ-16]

Hi @filiperochalopes, I’ve opened a PR addressing this issue.
Please feel free to review it when you have time. I’d be happy to make any changes if needed. Thanks!

[snyaggarwal]

@filiperochalopes The implementation is to reuse only, and I have tested this.
The only issue is with this flow -- Run Auto Match and then open a row which is not yet Auto-Matched.
Auto-match runs in batches and goes through rows one after the other, and each batch can take some time to return results.
During this processing time, if a row is opened, then we re-fetch the candidates, which can be avoided.

[PratikshaJ-16]

hi @snyaggarwal , Thanks for pointing this out!
That makes sense - the edge case where a row is opened before its batch completes can still trigger redundant calls.
I’ll look into handling in-progress batch states or preventing duplicate requests during processing. Happy to explore this as a follow-up improvement.

[filiperochalopes]

@snyaggarwal In addition to this edge case, I was also able to initiate recalls for completed requests with ready results, which is why I opened the issue. However, it might have been an older version. I will test again and provide updated follow-up information.

[filiperochalopes]

OK, checked, it does not seen to happen anymore, closing but @snyaggarwal please check #2444 that happened while I was testing