[Interpreter] Make interpreter execution cancellable

[lukasolson]

We need a way to "cancel" the execution of the interpreter under certain scenarios. This might be because a user has navigated away from a page, or because a new execution context is being requested to run that will replace the current execution.

For example, if a user has a visualization embedded on a dashboard, changes the query, and then submits, there is no reason to continue the execution of the current chain, as it will be replaced anyway.

I propose adding something similar to an AbortSignal to the expression runner options. Then, inside the interpreter, before executing each function, we can check if the signal has been aborted before executing the function. We'll also have to pass this signal into functions themselves (maybe inside the handlers) so that they can actively handle cancelling anything currently in progress (such as a request).

/cc @ppisljar @lukeelmers

[elasticmachine]

Pinging @elastic/kibana-app-arch

[ppisljar]

/cc @timroes

agreed, this is part of functionality that is still missing as far as i am aware, and i like your proposition of using abort signal.

[lukeelmers]

++ This approach makes sense to me.

So basically:

const controller = new AbortController();
await data.expressions.run('foo | bar', { signal: controller.signal });

And in your interpreter functions:

async fn(context, args, { signal }) {
  signal.addEventListener('abort', () => console.log('cleanup'));
}

Or I suppose you could alternatively expose the abort event as an observable in the handler.

[ppisljar]

most functons shouldn't need to implement this, interpreter should handle this on its own (if abort signal fired then it should quit after currenty executing function terminates.

functions would use this in advanced use cases (for example esaggs function would be passing this abort signal to kfetch (or whatever)

[timroes]

Despite the fact, that I think we should not use EventEmitters, because they are not properly typeable, but instead should reach in some proper oberservables for the individual signals, I think the functionality of this is rather good, because as Peter mentioned most functions most likely won't need some special handling for that.

[lukasolson]

Resolved by #40238.