Context should allow Kibana users to unambiguously identify the source of a query in the Kibana App in the browser, Kibana server, or the task manager.

interface KibanaExecutionContext {
  // kibana entity type
  type: 'visualization' | 'actions' | 'alert' | ..;
  // kibana entity id
  id: string;
  // human readable description, a vis title, action name,
  description: string;
  // in browser - url to navigate to a current page, on server - endpoint path, for task: task SO url
  url?: string;
}

Client-side

APM RUM agent doesn't provide support for async context propagation in the browser. Kibana will have to implement manual context passing.

A plugin creates an execution context object with API provided by Core. Returned value is opaque to the plugin.

const executionContext: KibanaExecutionContext = createExecutionContext({ .. })

Obtained execution context should be passed to the Kibana server manually through all the layers of abstractions in Kibana. Kibana sets it as a custom request header before issuing a request to the Kibana server:

await fetch('/api/something', {
  headers: {
    'kbn-context': executionContext.toString(),
  }
});

In the next iteration, we will use the APM RUM agent for content propagation to get rid of the custom 'kbn-context' header.

Server-side

A service provides a similar API on the server-side. The main difference is the context metadata is attached to the active APM transaction instead of the necessity to pass it manually.

Subtasks

• Initial implementation Add execution context service #102039
• Add nested context support. Developers should be able to link execution context object to model their relationships: app --> dashboard --> visualization, app --> canvas --> visualization