Bug Description

The ResourceLocator component incorrectly caches search results to the current search key, even when those results correspond to a previous search key. This occurs when the search query changes while a request is still in flight.

Specifically, when a response arrives, the component caches it under the original key (correct) but also under the currentRequestKey if it differs (incorrect). This means if a user types abc (triggering a request) and then changes it to xyz while the request is pending, the results for abc are cached and displayed for xyz.

This issue was introduced in PR #16773.

It is particularly egregious on the first load of the dropdown because there is no debounce delay, making it very likely for a user to start typing while the initial "empty" search is loading.

To Reproduce

There's probably easier ways to reproduce this, but this is the one I stumbled upon.

1. Add an lmChatOpenAi node to a workflow and configure OpenAI credentials.
2. Click the "Model" dropdown to start loading the list.
3. Immediately start typing a query (e.g., "turbo") before the initial list loads.
4. Observe that when the initial load finishes, the full list (or results for the empty query) is displayed and cached for your typed query "turbo", ignoring your filter.

Alternative reproduction with network throttling

1. Set network throttling in browser dev tools to increase latency.
2. Type a model name (e.g., "turbo") to trigger a search.
3. Wait 1s for the trailing debounce to trigger the request (verify in the Network tab when the request is made).
4. While the request is pending, change the query to something else (e.g., "turbooo").
5. Wait for the "turbo" request to resolve.
6. Observe that the results for "turbo" are now cached and displayed for "turbooo".

Expected behavior

Search results should only be cached for the specific query parameters that generated them. If the user changes the search query while a request is pending, the results from the previous request should be discarded or cached only for the original key, not the new one. The UI should reflect the state of the current query (loading or results specific to that query).

Debug Info

Debug info

core

• n8nVersion: 1.121.0
• platform: docker (self-hosted)
• nodeJsVersion: 22.21.0