feat: add UI trigger for query progress

[Swiddis]

WIP -- for now I've added handling for non-terminal progress, I'm still working on how to use the trigger interface here: https://opensearch-project.github.io/OpenSearch-Dashboards/docs/#/../src/plugins/ui_actions/README. Never used something that requires an ID in a generic like this and getting syntax errors when I try to copy what other plugins are doing, so still WIP.

Issue: #25

[kavilla]

unrelated to this PR but thought I get your feedback on this function.

when i refactored this a little I kept intact like the returning of a boolean but it returns false because the rxjs operator takeWhile needs to get the false value to stop polling.

but it's confusing to read do you think it's worth to rename this function? or shift the logic so that in the utils function it negates the value here? Because return false when SUCCESS from onPollingSuccess could get confusing.

[Swiddis]

It could be confusing at first, but I think it's generally derivable that the usage is to return false to halt polling and true to continue. There isn't anything inherently "keep polling"-like about true or false.

If we want to make it more clear I think the way to go would be to refactor the polling util to rely on a polling state enum, and return values like Polling.DONE, Polling.CONTINUE, Polling.ERROR. Could even make it more sophisticated with the specific statuses, having things like TIMEOUT or ABORT.

[Swiddis]

Not sure if it's obvious by me introducing JobState to begin with, but I'm a big fan of using state machines and strong typing (i.e. lots of enums) to keep track of program state and handle errors.

[Swiddis]

Keeping as draft while I figure out how the caller should consume the actions, might not need to filter by query ID param and might need to include additional info in the action context.

[Swiddis]

Alright: got something actually working. Sends query data to the ASYNC_TRIGGER_ID trigger. From the caller side you need to make a Subject that accepts the async query type. (To avoid cross-plugin imports this type also has to be redefined). Here's a sample method to create one of those (given a constant with the same async trigger id, and assuming the trigger ids have been registered):

import { Subject } from 'rxjs';
import { UiActionsStart, createAction } from '../../../ui_actions/public';
import { ASYNC_TRIGGER_ID, ASYNC_ACTION_ID } from '../../common';

interface AsyncQueryContext {
  queryId: string;
  queryStatus: string;
}

export function createQueryProgressSubject(uiActions: UiActionsStart): Subject<AsyncQueryContext> {
  const subject: Subject<AsyncQueryContext> = new Subject();
  uiActions.addTriggerAction(
    ASYNC_TRIGGER_ID,
    createAction<typeof ASYNC_ACTION_ID>({
      id: ASYNC_ACTION_ID,
      execute: async (context: unknown) => subject.next(context as AsyncQueryContext),
    })
  );
  return subject;
}

Then from the plugin start method you can create a subject:

const progressSubject = createQueryProgressAction(uiActions);

And pass this to the front-end where you can subscribe in order to update the progress:

const [progress, setProgress] = useState('NONE');
data.progressSubject.subscribe((v) => setProgress(v.queryStatus));

Pretty roundabout and far from ideal (requires lots of boilerplate to onboard the progress subject + query types + registration + passing all the refs around), but it gets the job done. We'll also require that the progress type is kept backwards-compatible, but otherwise should be pretty manageable.

[ashwin-pc]

Pretty roundabout and far from ideal (requires lots of boilerplate to onboard the progress subject + query types + registration + passing all the refs around)

Yeah for some of the simpler usecases we should add some abstractions inside the UI Actions plugin itself to make using it easier. Abstracting some this into the UI actions plugin directly would save future developers time here.

We'll also require that the progress type is kept backwards-compatible

What do you mean by this?

[Swiddis]

If we change the progress object type, other plugins will be depending on it, so it'll be a wider change -- by my count at least 3 plugins are going to be using this interface after it's ready (data/query workbench/observability)

This requirement probably exists already, but since we redefine the type in other plugins it won't be type-checked automatically if we do need to change it and track down all the downstream changes.

[Swiddis]

opensearch-project/OpenSearch-Dashboards#7337