RI-7614 Introduce shared commands history (for Search and Workbench) #5057

valkirilov · 2025-10-13T08:20:49Z

Description

Introduce a simple abstraction layer for fetching Command History data from any data source.

Currently, we support storing this information in two places:

SQLite
IndexedDB

And we don't have a simple way to CRUD the data in a generic way, without having a highly coupled implementation dependent on the data store. With this pull request, we aim to introduce a way to make this more reusable and easier to extend in the future by creating a common interface that should be independent of the data source used behind it.

How it was tested

Using SQLite

This is the default data store, so when you start the application, go and execute a bunch of queries on both the Search and Workbench pages. The following should work as expected:

loading history
executing new commands or re-executing existing cooomands
expanding a row for additional details
removing a single history record
clearing all history records

Screen.Recording.2025-10-16.at.12.32.25.mov

Using IndexedDB

In order the toggle the data source and make the app use IndexedDB, put the following environment variable.

RI_FEATURES_ENV_DEPENDENT_DEFAULT_FLAG=false

Then, you can follow the same scenarios as for the SQLite variant.

Screen.Recording.2025-10-16.at.12.38.23.mov

More details

At this point, we do use the Command History on the Search and Workbench pages. And so far, its implementation has been inconsistent:

on Workbench, we can store this information in SQLite or Index DB (toggleable via a feature flag), and it goes in Redux
on Search page, we were storing this only in Index DB, we don't have the feature flag toggle, and we store it wrong inside the Workbench index. And lastly, it's using a hook with local React state, it's completely independent from Redux.

With this pull request, we aim to introduce a generic way to handle this, but we'll focus on the implementation for the Search page only, which is the problematic one. Later on, we can easily bind the Workbench implementation to the new services, because they're built in a way that can be easily reused across the codebase (or at least, this is the plan)

Notes

Here is a short breakdown of the concepts introduced by this pull request:

created an interface to define the behavior for the services that should fetch command history data (no matter of the data source). It's a really simple CRUD, and all services should implement it when interacting with various data sources (SQLite, IndexedDB, etc.)
created an example implementation for fetching command history data from both SQLite and IndexedDB
created a service to toggle the data source when fetching commands history data, based on a feature flag and target SQLite or IndexedDB
extend the IndexedDB database, to support storage for both Search and Workbench pages, using the same schema.
apply the changes only to the Search page related functionalities. The Workbench page remains untouched and operational, but can be updated in the future to use the same service.

PS: There are more comments bellow, scroll down.

- created interface to define the behavior for the services that should fetch commands history data (no matter of the data source) - created example implementation for fetching commands history data from SQLite - created hook to toggle the data source when fetching commands history data, based on a feature flag and target SQLite or INdexDB re #RI-7614

valkirilov · 2025-10-13T08:26:33Z

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

    const loadHistory = async () => {
      try {
-        const historyData = await loadHistoryData(instanceId)
+        const historyData = await getCommandsHistory(instanceId)


My goal is to preserve the current way of managing command history through the Search page (with this hook) while modifying only the underlying logic responsible for interacting with the data store.

This approach ensures that the existing components remain unchanged, while simultaneously achieving the goal of having an independent data store that can be easily changed via a feature flag.

And of course, by design, this hook (and the components that depend on it) remain unaware of this information, and they will not be affected by any future changes of the data source behind it.

redisinsight/ui/src/services/commands-history/database/CommandsHistoryIndexedDB.ts

redisinsight/ui/src/services/commands-history/hooks/useCommandsHistory.ts

valkirilov · 2025-10-13T08:31:44Z

redisinsight/ui/src/services/commands-history/database/interface.ts

+  CommandExecutionUI,
+} from 'uiSrc/slices/interfaces'
+
+export interface CommandsHistoryDatabase {


This is the interface that every service should comply with. It's basic CRUD, simple as that. And it's independent from the data source behind it.

valkirilov · 2025-10-13T08:33:37Z

redisinsight/ui/src/services/commands-history/database/CommandsHistorySQLite.ts

+import { mapCommandExecutionToUI } from '../utils/command-execution.mapper'
+import { CommandsHistoryDatabase, CommandHistoryResult } from './interface'
+
+export class CommandsHistorySQLite implements CommandsHistoryDatabase {


This is an i(example) implementation of the service that should work with the Commands History stored in the SQLite database. It should follow the common interface and keep all of the business login encapsulated inside it.

re #RI-7614

redisinsight/ui/src/services/commands-history/hooks/useCommandsHistory.ts

redisinsight/ui/src/services/commands-history/utils/command-execution.mapper.ts

- extend the generic service (and the database related implemnetations) to support adding/running commands - replace the existing implementation for running commands and ssaving the history, on the new Search page re #RI-7614

re #RI-7614

- it was meant to be a hook only because we need a feature flag to capture which data store shold be used, but after some comments, it's changed to be just a service re #RI-7614

re #RI-7614

…page re #RI-7614

re #RI-7614

…r commands history re #RI-7614

re #RI-7614

valkirilov · 2025-10-16T09:45:17Z

redisinsight/ui/src/config/default.ts

    localResourcesBaseUrl: process.env.RI_LOCAL_RESOURCES_BASE_URL,
    useLocalResources: booleanEnv('RI_USE_LOCAL_RESOURCES', false),
    indexedDbName: process.env.RI_INDEXED_DB_NAME || 'RI_LOCAL_STORAGE',
+    vectorSearchIndexedDbName:


Adding a separate IndexedDB for the Search page (as advised here).

It will use the same interface like the Workbench, but the Commands History related to these pages will live independently.

valkirilov · 2025-10-16T09:48:13Z

redisinsight/ui/src/services/vectorSearchHistoryStorage.ts

+
+const riConfig = getConfig()
+
+export const vectorSearchCommandsHistoryStorage = new WorkbenchStorage(


Adding a separate IndexedDB for the Search page (as advised here).

It will use the same interface like the Workbench, but the Commands History related to these pages will live independently.

valkirilov · 2025-10-16T09:49:44Z

redisinsight/ui/src/services/workbenchStorage.ts

 type CommandHistoryType = CommandExecution[]

-export async function getLocalWbHistory(dbId: string) {
+export async function getLocalWbHistory(


Extending all the methods to support picking the database instance (as advised here).

The end goal is to keep it simple yet generic, so both the Search and Workbench pages will use the same methods for CRUD related to their Command History stored in IndexedDB.

if all of these methods require a WorkbenchStorage instance as a first parameter, then why not make them methods of WorkbenchStorage class?

I'm not sure what the original idea was behind this implementation back then, when it was originally introduced. Maybe it was not considered that one day it would serve two different pages.

In my previous pull request, I have changed the original implementation of the WorkbenchStorage and it was advised here that it's not the correct approach to extend it. That's why I have followed the provided suggestion in this implementation, simply by extending the helper methods instead of the original class.

valkirilov · 2025-10-16T09:51:22Z

redisinsight/ui/src/services/commands-history/commandsHistoryService.ts

+import { CommandsHistoryDatabase } from './database/interface'
+import { CommandsHistoryIndexedDB } from './database/CommandsHistoryIndexedDB'
+
+export class CommandsHistoryService {


This is the main service that should be used when working with Command History data:

it defines all the necessary CRUD operations for dealing with this type of data

and it does the magic to target the correct data source, based on a feature flag, hiding these implementation details from its consumers

github-actions · 2025-10-16T09:58:56Z

Code Coverage - Frontend unit tests

St.^❔	Category	Percentage	Covered / Total
🟢	Statements	82.13%	20107/24482
🟡	Branches	67.54%	8700/12881
🟡	Functions	76.16%	5341/7013
🟢	Lines	82.55%	19689/23850

Test suite run success

5225 tests passing in 681 suites.

Report generated by 🧪jest coverage report action from eddc5f3

dantovska · 2025-10-20T08:22:34Z

redisinsight/ui/src/services/commands-history/database/CommandsHistoryIndexedDB.ts

+  wbHistoryStorage,
+  WorkbenchStorage,
+} from 'uiSrc/services/workbenchStorage'
+import { C } from 'msw/lib/glossary-2792c6da'


nit: I think we don't need this?

Thanks for spotting this, now it's removed 🙌

valkirilov force-pushed the fe/feature/RI-7614_search-commands-history branch from 756fab1 to 5f6d57f Compare October 13, 2025 08:22

valkirilov commented Oct 13, 2025

View reviewed changes

redisinsight/ui/src/services/commands-history/database/CommandsHistoryIndexedDB.ts Outdated Show resolved Hide resolved

valkirilov commented Oct 13, 2025

View reviewed changes

redisinsight/ui/src/services/commands-history/hooks/useCommandsHistory.ts Outdated Show resolved Hide resolved

valkirilov commented Oct 13, 2025

View reviewed changes

valkirilov self-assigned this Oct 13, 2025

valkirilov changed the title ~~RI-7614 Introduce abstraction layer for commands history~~ RI-7614 Introduce shared commands history (for Search and Workbench) Oct 13, 2025

test(ui): added tests for the new commands history services layer

2ab6faf

re #RI-7614

KrumTy reviewed Oct 14, 2025

View reviewed changes

redisinsight/ui/src/services/commands-history/hooks/useCommandsHistory.ts Outdated Show resolved Hide resolved

redisinsight/ui/src/services/commands-history/utils/command-execution.mapper.ts Show resolved Hide resolved

valkirilov added 10 commits October 14, 2025 13:24

feat(ui): added method for running commands

29af575

- extend the generic service (and the database related implemnetations) to support adding/running commands - replace the existing implementation for running commands and ssaving the history, on the new Search page re #RI-7614

test(ui): added tests for "addCommandsToHistory" methods

dd09d60

re #RI-7614

refactor(ui): replace hook with regular service

0057330

- it was meant to be a hook only because we need a feature flag to capture which data store shold be used, but after some comments, it's changed to be just a service re #RI-7614

feat(ui): added delete command history command

3530f38

re #RI-7614

refactor(ui): minor refactoring in the tests

d781313

re #RI-7614

feat(ui): added "clear commands" helper

adaa5b4

re #RI-7614

feat(ui): added IndexedDb support for Commands History on the Search …

c16afe3

…page re #RI-7614

feat(ui): added support for reading single command from the history

93a1318

re #RI-7614

feat(ui): update create vector search index to us ethe new service fo…

f3d6c9f

…r commands history re #RI-7614

test(ui): update tests to use t he correct mock

bec64b6

re #RI-7614

valkirilov commented Oct 16, 2025

View reviewed changes

valkirilov marked this pull request as ready for review October 16, 2025 13:47

valkirilov requested review from ArtemHoruzhenko, dantovska and pawelangelow as code owners October 16, 2025 13:47

valkirilov requested a review from pd-redis as a code owner October 16, 2025 13:47

dantovska reviewed Oct 20, 2025

View reviewed changes

dantovska previously approved these changes Oct 20, 2025

View reviewed changes

reafctor(ui): remove unncessasry import

eddc5f3

valkirilov dismissed dantovska’s stale review via eddc5f3 October 20, 2025 09:28

dantovska approved these changes Oct 20, 2025

View reviewed changes


		const riConfig = getConfig()

		export const vectorSearchCommandsHistoryStorage = new WorkbenchStorage(

RI-7614 Introduce shared commands history (for Search and Workbench) #5057

Are you sure you want to change the base?

RI-7614 Introduce shared commands history (for Search and Workbench) #5057

Conversation

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

Uh oh!

Description

How it was tested

Using SQLite

Using IndexedDB

More details

Notes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

valkirilov Oct 13, 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!

valkirilov Oct 13, 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!

Uh oh!

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!

github-actions bot commented Oct 16, 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

valkirilov commented Oct 13, 2025 •

edited

Loading

valkirilov Oct 13, 2025 •

edited

Loading

valkirilov Oct 13, 2025 •

edited

Loading

github-actions bot commented Oct 16, 2025 •

edited

Loading