[Meta] Implement context propagation for Kibana entities

[mshustov]

Use the service introduced in https://github.com/elastic/kibana/issues/102626 to instrument Kibana code with runtime context metadata: Phase I:

• Visualizations
  • [x] vis_type_metric
  • [x] vis_type_table
  • [x] vis_type_tagcloud
  • [x] vis_type_timelion
  • [x] vis_type_timeseries
  • [x] vis_type_vega
  • [x] vis_type_vislib
  • [x] vis_type_xy
  • [x] vis_type_pie
  • [ ] input_controls_vis
• [x] Lens
• [x] Discover
• [x] Dashboards
• [ ] Kibana server request handlers
• Tasks
  • [x] Actions
  • [x] Alerts

Phase II (TBD dates)

• [ ] https://github.com/elastic/kibana/issues/132629 (replaces all issues bellow
• [x] Propagate execution context from Maps
• [x] Propagate execution context from Dev Tools
• [x] #126802
• [ ] #126797
• [ ] #126798
• [x] #126799
• [x] #126800
• [ ] #126801
• Tasks
  • [ ] Reporting

Acceptance Criteria

1. Execution context propagates from a Kibana frontend application to the Core service of the Kibana server (if applicable).
2. Execution context propagates from a Kibana backend application to the Core service of the Kibana server (if applicable).
3. The integration has an appropriate integration test.

Nested context

https://github.com/elastic/kibana/issues/102626 will add the ability to create nested / linked contexts. It can be used to compose execution context relationships across different apps. Application service context --> Dashboard context --> Visualization context.

Integration with embeddable

As discussed with @ppisljar we need to extend EmbeddableInput interface with executionContext https://github.com/elastic/kibana/blob/859caf22c0d6560961d55e680ea35b1aed33a498/src/plugins/embeddable/common/types.ts#L16 In the turn, every application creating an embeddable container will create application-specific execution context object and provide it as a part of input when calling updateInput https://github.com/elastic/kibana/blob/859caf22c0d6560961d55e680ea35b1aed33a498/src/plugins/embeddable/public/lib/embeddables/embeddable.tsx#L152

How to test

automatic testing

It's better to automate the check to prevent unexpected failures in the future. You can use these files as a referenced implementation of the functional tests. for the client side code for the server side code

manual testing

Steps to test the PR manually:

• setup logging to observe request.id: opaqueId in elasticsearch response and execution_context whenever it's set

  logging:
  appenders:
  myconsole:
    type: console
    layout:
      type: pattern
      pattern: '%date|%meta'
  loggers:
  - name: elasticsearch.query
    level: all
    appenders: [myconsole]
  - name: execution_context
    level: debug
    appenders: [console]

• run Kibana
• navigate to your app
• simulate user interactions that lead to ES requests
• You should be able to see the log output like this:

  
  [2021-07-12T13:14:28.944+03:00][DEBUG][execution_context] stored the execution context: {"requestId":"d568e29f-c3de-4ef6-a311-225b1358f8b7","type":"visuzalization","name":"gauge","description":"[eCommerce] Average Sales Price","id":"4b3ec120-b892-11e8-a6d9-e546fe2bba5f","url":"/bon/app/visualize#/edit/4b3ec120-b892-11e8-a6d9-e546fe2bba5f"}

2021-07-12T13:14:28.965+03:00|{"http":{"request":{"id":"d568e29f-c3de-4ef6-a311-225b1358f8b7;kibana:visuzalization:gauge:4b3ec120-b892-11e8-a6d9-e546fe2bba5f"}}}

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[lizozom]

I think that the merge of https://github.com/elastic/kibana/pull/124996 changes the second phase of this issue. Instead of propagating the context manually, solutions should make sure to call useExecutionContext on their pages, similar to what we did for discover, visualize, dashboard, maps and dev_tools on that PR.

I think we could create issues for solutions to start working on it at their own pace. What do you think?

[mshustov]

Instead of propagating the context manually, solutions should make sure to call

I wouldn't say these things are mutually exclusive, but rather they complement each other. We can ask Solution teams to instrument their code with useExecutionContext as Phase II, but why not propagate context manually at the same time if possible? We can postpone manual propagation until Phase III for cases requiring significant effort.

[xcrzx]

@lizozom @mshustov I have created an issue on implementing a generic solution to execution context propagation: https://github.com/elastic/kibana/issues/132629. Which I have already partially implemented in this PR. So I think tasks in this epic from the phase II are not needed anymore and can be closed.

[lizozom]

@xcrzx thank you! I've crossed the remaining items out. Is https://github.com/elastic/kibana/issues/132629 something you're considering to take on?

[xcrzx]

Is https://github.com/elastic/kibana/issues/132629 something you're considering to take on?

Yea, I think so. Just need to align with my team before taking that task. I'll come back to you with an update, likely at the beginning of next week.

[lukeelmers]

@lizozom Just to confirm, we skipped manually implementing context propagation in Canvas, Observability, Enterprise Search, and Reporting, in favor of https://github.com/elastic/kibana/issues/132629 -- correct? I assume those apps will need to switch to using the shared router then