RI-7614 Filter Query Results based on the type of the page #5043

valkirilov · 2025-10-07T12:43:53Z

Description

Show the correct command results on the Search and Workbench pages, by filtering out the queries based on the page from which they were executed.

make sure we use the feature flag to toggle the data source (Index DB or SQLite) for the Search page as well (like it's done for the Workbench page)
show filtered commands when using IndexDB (based on their type, matching the page)
show filtered commands when using SQLite (rework the main hook that was responsible to CRUD the history, so it can work for the Search page as well)
extended the IndexDB indexes to support easier deletion by type (Search/Workbench), when using the "Clear results" button. It should remove only commands related to the page, not all of them

Screen.Recording.2025-10-07.at.16.36.08.mov

Before	After

How it was tested

We have two available ways to store the history of the executed commands - SQLite and IndexDB inside the browser itself.

Using Index DB

Create redisinsight/ui/.env and make sure to put RI_FEATURES_ENV_DEPENDENT_DEFAULT_FLAG=false inside it.

Using SQLite

It's the default mode, but in case you added RI_FEATURES_ENV_DEPENDENT_DEFAULT_FLAG make sure to flip it to true

Reproduction Steps

Go to Databases and open a connection to an existing database instance, ot create a new one
Open the Search page and execute a command inside the code editor (like SEARCH COMMAND)
Go to the Workbench page and execute another command (like WORKBENCH COMMAND)

Switch between the pages and make sure you see the correct commands in the list with the results.

Search	Workbench

- makse sure to follow the guidelines defined by the Workbecnh page, so do save query results in IndexDB only when the respective feature flag allows it ire #RI-7602

- filter out the history loaded from the IndexDB, based on the type of the commands, so we can show it accordingly to the Search and Workbench pages re #RI-7602

github-actions · 2025-10-07T12:49:32Z

Code Coverage - Frontend unit tests

St.^❔	Category	Percentage	Covered / Total
🟢	Statements	81.97%	19951/24339
🟡	Branches	67.35%	8640/12828
🟡	Functions	75.87%	5296/6980
🟢	Lines	82.39%	19532/23706

Test suite run success

5170 tests passing in 677 suites.

Report generated by 🧪jest coverage report action from e92d15d

- extend the IndexDB indexes to allow easier deletion of records by their type (search/workbench) - apply the new deletion logic on the search and workbench pages re #RI-7614

valkirilov · 2025-10-07T13:23:23Z

redisinsight/ui/src/pages/vector-search/create-index/hooks/useCreateIndex.ts


        // Step 3: Persist results locally so Vector Search history (CommandsView) shows it
-        if (Array.isArray(data) && data.length) {
+        if (envDependentFlag === false && Array.isArray(data) && data.length) {


We don't want to preserve the commands inside IndexDB always, it should depend on this feature flag, as it's handled in the Workbench.

I don't think this should be done on this layer. Ideally we must always call addCommands and then have a storage strategy based on envDependent flag

First, addCommands is tightly related to wbHistoryStorage, it is not meant to be general solution for command history storage. Internally it uses WorkbenchStorage class, that is writing to IndexedDb.
Same or similar thing can be applied to search history storage. Since it is new implementation, I agree with Artem, that better approach would be an implementation, that takes a useBackendPersistanse = false flag and internally decides how to store the commands, but using addCommands will ALWAYS add these commands to workbench history, which is apparently a problem

valkirilov · 2025-10-07T13:24:04Z

redisinsight/ui/src/pages/vector-search/query/useQuery.ts

      })

-      await addCommands(reverse(data))
+      if (envDependentFlag === false) {


We don't want to preserve the commands inside IndexDB always, it should depend on this feature flag, as it's handled in the Workbench.

valkirilov · 2025-10-07T13:26:29Z

redisinsight/ui/src/services/workbenchStorage.ts

+          })
+          objectStore.createIndex(
+            CommandExecutionIndex.DatabaseIdType,
+            ['databaseId', 'type'],


We should only remove the records related to the page (Search/Workbench) when clicking the “Clear Results” button. Instead of adding an additional check in the cursor (which iterates over the records while deleting them), I’m introducing a new index that can easily target the correct type.

However, if you find this approach to be incorrect, I can revert to the iterative deletion method.

I thinks this is wrong approach. Do not change WorkbenchStorage class to differentiate between storage types, just create vectorSearchHistoryStorage

export const vectorSearchHistoryStorage = new WorkbenchStorage( riConfig.app.vectorSearchName, 2, )

And if you want to generalize addCommands, getLocalWbHistory etc, modify them to accept the storage instance

valkirilov · 2025-10-07T13:31:03Z

redisinsight/ui/src/services/workbenchStorage.ts

-          const idbIndex = objectStore?.index('dbId')
-          const indexReq = idbIndex?.openCursor(dbId)
+          const idbIndex = objectStore?.index(indexName)
+          const indexReq = idbIndex?.openCursor(indexSelector)


Here, we simply pass the database instance and the type we target (search or workbench), and it will do it.

const idbIndex = objectStore?.index('dbId_type') const indexReq = idbIndex?.openCursor(['databaseId', 'SEARCH'])

Of course, we still support the old behavior, so you can still target a specific database instance and delete all records related to it.

const idbIndex = objectStore?.index('dbId') const indexReq = idbIndex?.openCursor('databaseId')

Otherwise, we should delete the records by their type inline, inside the cursor below.

valkirilov · 2025-10-07T13:32:07Z

redisinsight/ui/src/services/workbenchStorage.ts

+    }

-    return history || []
+    return history.filter((item) => item.type === commandExecutionType)


Here we do the magic to apply some filtering, based on the type (Search/Workbench), so we don't show the full history on both pages.

- rework the hooks responsible to keep the commands history for the searach page (on desktop) to use the redux store, like the workbench re #RI-7614

valkirilov · 2025-10-08T13:35:04Z

redisinsight/ui/src/pages/vector-search/query/useQuery.ts


  const resultsMode = ResultsMode.Default
  const activeRunQueryMode = RunQueryMode.ASCII
+  const executionType = CommandExecutionType.Search


Basically, we need to rely on the current implementation for the history manipulation (and automatically switch between SQLite and IndexDB based on the feature flag), so we should go for the existing helpers instead of building them again.

ArtemHoruzhenko · 2025-10-09T06:30:22Z

redisinsight/ui/src/pages/vector-search/create-index/hooks/useCreateIndex.ts

+  const envDependentFlag = useSelector(
+    (state: RootState) =>
+      state?.app?.features?.featureFlags?.features?.envDependent?.flag,
+  )


I feel like we must return envDependent: { flag: boolean} here and use it below like envdepenent.flag

I see we have appFeatureFlagsFeaturesSelector Redux selector, so we can rely on it, or create a new one for this envDependant flag as well. It should be applied to a few more places in the app as well.

ArtemHoruzhenko · 2025-10-09T06:32:20Z

redisinsight/ui/src/pages/vector-search/create-index/hooks/useCreateIndex.ts


        // Step 3: Persist results locally so Vector Search history (CommandsView) shows it
-        if (Array.isArray(data) && data.length) {
+        if (envDependentFlag === false && Array.isArray(data) && data.length) {


I don't think this should be done on this layer. Ideally we must always call addCommands and then have a storage strategy based on envDependent flag

pd-redis · 2025-10-09T08:14:03Z

redisinsight/ui/src/pages/vector-search/create-index/hooks/useCreateIndex.ts


        // Step 3: Persist results locally so Vector Search history (CommandsView) shows it
-        if (Array.isArray(data) && data.length) {
+        if (envDependentFlag === false && Array.isArray(data) && data.length) {


First, addCommands is tightly related to wbHistoryStorage, it is not meant to be general solution for command history storage. Internally it uses WorkbenchStorage class, that is writing to IndexedDb.
Same or similar thing can be applied to search history storage. Since it is new implementation, I agree with Artem, that better approach would be an implementation, that takes a useBackendPersistanse = false flag and internally decides how to store the commands, but using addCommands will ALWAYS add these commands to workbench history, which is apparently a problem

pd-redis · 2025-10-09T08:27:00Z

redisinsight/ui/src/services/workbenchStorage.ts

+          })
+          objectStore.createIndex(
+            CommandExecutionIndex.DatabaseIdType,
+            ['databaseId', 'type'],


I thinks this is wrong approach. Do not change WorkbenchStorage class to differentiate between storage types, just create vectorSearchHistoryStorage

export const vectorSearchHistoryStorage = new WorkbenchStorage( riConfig.app.vectorSearchName, 2, )

And if you want to generalize addCommands, getLocalWbHistory etc, modify them to accept the storage instance

valkirilov added 2 commits October 7, 2025 15:31

fix(ui): stop saving vector search queries in IndexDB

e958794

- makse sure to follow the guidelines defined by the Workbecnh page, so do save query results in IndexDB only when the respective feature flag allows it ire #RI-7602

fix(ui): resolve issues with workbench/search history

9261322

- filter out the history loaded from the IndexDB, based on the type of the commands, so we can show it accordingly to the Search and Workbench pages re #RI-7602

fix(ui): clear query results to target only search/workbench commands

1fb89cd

- extend the IndexDB indexes to allow easier deletion of records by their type (search/workbench) - apply the new deletion logic on the search and workbench pages re #RI-7614

valkirilov commented Oct 7, 2025

View reviewed changes

valkirilov self-assigned this Oct 8, 2025

fix(ui): update the search/workbench history for desktop app

e92d15d

- rework the hooks responsible to keep the commands history for the searach page (on desktop) to use the redux store, like the workbench re #RI-7614

valkirilov commented Oct 8, 2025

View reviewed changes

valkirilov marked this pull request as ready for review October 8, 2025 13:35

valkirilov requested review from ArtemHoruzhenko, KrumTy, dantovska, pawelangelow and pd-redis as code owners October 8, 2025 13:35

ArtemHoruzhenko reviewed Oct 9, 2025

View reviewed changes

pd-redis requested changes Oct 9, 2025

View reviewed changes

valkirilov closed this Oct 9, 2025

RI-7614 Filter Query Results based on the type of the page #5043

RI-7614 Filter Query Results based on the type of the page #5043

Uh oh!

Conversation

valkirilov commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

How it was tested

Using Index DB

Using SQLite

Reproduction Steps

Uh oh!

github-actions bot commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage - Frontend unit tests

Test suite run success

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

valkirilov Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

valkirilov commented Oct 7, 2025 •

edited

Loading

github-actions bot commented Oct 7, 2025 •

edited

Loading

valkirilov Oct 7, 2025 •

edited

Loading