Fix context.pageName by fixing missing executionContext #201118
Fix context.pageName by fixing missing executionContext #201118maryam-saeidi wants to merge 11 commits intoelastic:mainfrom
Conversation
|
Hi @kpatticha , I checked this implementation for APM pages to ensure this does not interfere with APM custom implementation, and it looks fine to me: Was APM the only application with a custom logic? Do you mind testing this PR and verify if the previous custom implementations still have the same context.pageName? |
@maryam-saeidi, if I understand correctly it is any places where Or |
Tested APM and it works as expected 💯 I've noticed the following in security timeline page. The localhost seems correct to me but it might worth checking or inform the team that the fix in this PR could potentially impact their telemetry data Also, @afharo opened a PR trying to address the same problem #200785 .Have you had a chance to review it? It might be worth coordinating to avoid duplicating efforts. 😊 |
| /** The `ExecutionContextStart` API from `CoreStart`. */ | ||
| executionContext?: ExecutionContextStart; |
There was a problem hiding this comment.
Q: to avoid errors in the future, should we make this one mandatory?
There was a problem hiding this comment.
I will check to see if it is OK to make this dependency mandatory.
Still, I don't think this will prevent similar issues in the future because, eventually, it will be passed to SharedUXContext, which is initialized with an empty executionContext here.
|
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
@kpatticha Yes, I checked that PR, and I think since we already have |
| // setImmediate is required to ensure that EBT telemetry for the previous page is shipped before the new page is updated | ||
| setImmediate(() => { | ||
| // TODO: Remove this comment after testing | ||
| executionContext.set({ page: pathname }); |
There was a problem hiding this comment.
@kpatticha noticed a difference in the new context:
@elastic/security-solution Any idea how we can solve this issue?
In APM customized execution context, overriding the value is working as expected with the changes in this PR. I wonder what the difference between these two cases is.
There was a problem hiding this comment.
It seems like the same problem as with the data_quality page. The custom hook is called before the hook in our Route
There was a problem hiding this comment.
And there is slight implementation difference which is probably why the pageName is different
we use : const match = useRouteMatch(); match.path
security uses: const { pathname } = useLocation();
++! My PR was just exploration work... but this solution looks like a better approach |
davismcphee
left a comment
There was a problem hiding this comment.
Reviewed Data Discovery usages, LGTM 👍
| }); | ||
| }, [locator, referrer, services]); | ||
|
|
||
| // TODO: Remove this comment after testing |
There was a problem hiding this comment.
I reviewed our usages in Discover and dropping the custom overrides changes the context properties. E.g. for this one specifically:
page: "context" -> page: "/context/:dataViewId/:id"
entityId: "90943e30-9a47-11e8-b64d-95841ca0b247" -> entityId: "{\"dataViewId\":\"90943e30-9a47-11e8-b64d-95841ca0b247\",\"id\":\"Am8GZZMBvuc8nvvEfgGJ\"}"
I kept the overrides and removed the TODO here: 89b004b.
| }) => { | ||
| const { executionContext } = core; | ||
|
|
||
| // TODO: Remove this comment after testing |
There was a problem hiding this comment.
@maryam-saeidi this override is on purpose as described in
[Dataset quality] Adding execution context to data quality page within management app.
I removed the comment with fix(dataset-quality): remove TODO
However, it seems your changes are affecting how the pageName is sent for this app.
Before this PR, the pageName for dataset quality was constantly tracked as application:management:data_quality.
Visiting the same page on this PR, we get relative paths for the sub-router of this app instead of the target app.
Can't say exactly what is the turning point, but the values are different now 😕
There was a problem hiding this comment.
@maryam-saeidi, I think the problem here is that manual useExecutionContext() is called before the ones that are called in Routes, so Route overrides the custom one. Ideally the final one could look like this: "application: management: data_quality:details"
There was a problem hiding this comment.
APM and Infra look good. Profiling is not manually changing the execution context on route changes, as APM does it , so the context pageName never changes. Are going to address that in a separate PR?
Thanks for checking, Carlos. This is not part of this PR, and it is up to the teams at the moment. We can discuss this with |
| urlStateEnabled, | ||
| showCreateDashboardButton = true, | ||
| }: DashboardListingProps) => { | ||
| // TODO: Remove this comment after testing |
There was a problem hiding this comment.
dashboard changes LGTM, comment needs to be removed
ElenaStoeva
left a comment
There was a problem hiding this comment.
Thanks for working on this! Tested locally and some of the Kibana Management plugins have a different pageName context now.
| getUrlForApp: ApplicationStart['getUrlForApp']; | ||
| executionContext: ExecutionContextStart; | ||
| }) => { | ||
| // TODO: Remove this comment after testing |
| core: { executionContext }, | ||
| } = useAppContext(); | ||
|
|
||
| // TODO: Remove this comment after testing |
| history: ManagementAppMountParams['history']; | ||
| executionContext: ExecutionContextStart; | ||
| }) => { | ||
| // TODO: Remove this comment after testing |
| uiMetricService.trackUiMetric(UIM_POLICY_LIST_LOAD); | ||
| }, [uiMetricService]); | ||
|
|
||
| // TODO: Remove this comment after testing |
| core: { application, http, executionContext, ...startServices }, | ||
| } = dependencies.services; | ||
|
|
||
| // TODO: Remove this comment after testing |
⏳ Build in-progress
History
|
| setIndicateNoData(true); | ||
| }, [setIndicateNoData]); | ||
|
|
||
| // TODO: Remove this comment after testing |
There was a problem hiding this comment.
Not sure it is strictly related to this PR, but from my quick testing I see these page names from different flows:
Create visualizationin dashboard, opens a Lens editor =>application:lens:editor✅Create ES|QLpanel in dashboard =>application:dashboards:app❓Edit inlinein a Dashboard =>application:dashboard:app❓Edit in editorfrom a Dashboard inline editing panel =>application:lens:editor✅Edit visualizationin Discover =>application:lens:/edit_by_value❓
| ); | ||
|
|
||
| const editorName = savedVisInstance?.vis.type.title.toLowerCase().replace(' ', '_') || ''; | ||
| // TODO: Remove this comment after testing |
There was a problem hiding this comment.
I've checked this and noticed some subtle different pageName sometimes.
Nothing major, just these few issues:
application:visualizeandapplication:visualize:editorare used for similar flowsapplication:visualize:editor:xxxxxis triggered only on navigating back to dashboard from editor, not on enter
dej611
left a comment
There was a problem hiding this comment.
I've tested various flows for all the editors (Lens & legacy): the events are triggered correctly, not sure about their content as described in the inline comments, but at least they are there.
While it would be nice to have more context on my comment, I'll approve the PR to unblock it.
|
@maryam-saeidi We also use execution context for embeddables here, which doesn't seem to pass a Example of the embeddable context on the dashboard app{
"timestamp": "2024-12-03T16:31:19.632Z",
"event_type": "click",
"context": {
"isDev": true,
"isDistributable": false,
"version": "9.0.0",
"branch": "main",
"buildNum": 9007199254740991,
"buildSha": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"session_id": "e5b78d05-c775-4c58-b5c9-6e028e27fe8b",
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
"preferred_language": "en-GB",
"preferred_languages": [
"en-GB",
"en-US",
"en",
"ru",
"nl"
],
"viewport_width": 2511,
"viewport_height": 695,
"cluster_name": "default-9.0.0-main-1043",
"cluster_uuid": "zhJo9MR_Rbeh1w92AcwuZQ",
"cluster_version": "9.0.0-SNAPSHOT",
"cluster_build_flavor": "default",
"pageName": "dashboard:dashboards:app",
"applicationId": "dashboards",
"page": "app",
"entityId": "b702185d-5512-4597-b0dc-195e94c671ad",
"page_title": "ggg - Elastic",
"page_url": "/app/dashboards#/view/b702185d-5512-4597-b0dc-195e94c671ad?_g=(filters:!(),refreshInterval:(pause:!f,value:30000),time:(from:'2024-11-10T00:39:02.912Z',to:'2024-12-03T16:15:00.000Z'))",
"license_id": "66d90a0e-6eed-45fc-a2a4-08a9d21e60b3",
"license_status": "active",
"license_type": "trial",
"labels": {},
"discoverProfiles": [],
"userId": "986051385feae5b9850804db2d701c0b029ad24f09bce340c12aee7a5c8a0391",
"isElasticCloudUser": false
},
"properties": {
"target": [
"HTML",
"lang=en",
"BODY",
"class=coreSystemRootDomElement euiBody--headerIsFixed kbnBody kbnBody--noHeaderBanner kbnBody--chromeVisible kbnVersion-9-0-0",
"DIV",
"id=kibana-body",
"data-test-subj=kibanaChrome",
"DIV",
"class=kbnAppWrapper",
"data-test-subj=kbnAppWrapper visibleChrome",
"DIV",
"class=kbnAppWrapper",
"aria-busy=false",
"DIV",
"class=dashboardViewport",
"DIV",
"class=dashboardContainer",
"DIV",
"class=dshDashboardViewportWrapper",
"DIV",
"class=dshDashboardViewport",
"data-shared-items-container=true",
"data-title=ggg",
"data-shared-items-count=1",
"DIV",
"class=react-grid-layout dshLayout--editing",
"style=height: 428px;",
"DIV",
"class=dshDashboardGrid__item react-grid-item react-draggable react-resizable css-13nuqur-dashboard_grid_item--focusStyles",
"data-test-subj=dashboardPanel",
"id=panel-89ef8154-7ee0-46e0-8c17-2a40ccf249a4",
"data-grid=[object Object]",
"style=top: 8px; left: 0.318598%; width: 49.542%; height: 412px; position: absolute;",
"DIV",
"class=embPanel__hoverActionsAnchor css-1k23tud-presentation_panel_hover_actions--PresentationPanelHoverActions",
"data-test-subj=embeddablePanelHoverActions-MLanomalyswimlaneforcatrogy_example",
"data-test-embeddable-id=89ef8154-7ee0-46e0-8c17-2a40ccf249a4",
"DIV",
"class=euiPanel euiPanel--plain embPanel embPanel--editing css-szlwjt-euiPanel-grow-m-plain",
"role=figure",
"aria-labelledby=i00652701-b194-11ef-a80f-9f14aa095f80",
"data-test-subj=embeddablePanel",
"data-render-complete=true",
"DIV",
"class=embPanel__content",
"DIV",
"data-test-subj=mlAnomalySwimlaneEmbeddableWrapper",
"data-shared-item=",
"class=css-1osklss-anomaly_swimlane_embeddable_factory--Component",
"DIV",
"data-test-subj=mlSwimLaneEmbeddable_89ef8154-7ee0-46e0-8c17-2a40ccf249a4",
"class=euiFlexGroup css-12hn1m1-euiFlexGroup-none-flexStart-stretch-column-swimlane_container--SwimlaneContainer",
"DIV",
"class=euiFlexItem css-18qej2d-euiFlexItem-growZero-swimlane_container--SwimlaneContainer",
"DIV",
"DIV",
"class=css-1h3qr3u-swimlane_container--SwimlaneContainer",
"style=height: 154px;",
"DIV",
"class=echChart",
"style=width: 100%; height: 100%;",
"DIV",
"class=echChartContent mlSwimLaneContainer echChartContent--column",
"DIV",
"class=echContainer",
"DIV",
"class=echChartPointerContainer",
"style=cursor: pointer;",
"FIGURE",
"aria-describedby=e71a3f69-ae2b-4e0d-856e-677abf63217f--defaultSummary",
"CANVAS",
"class=echCanvasRenderer",
"width=2456",
"height=240",
"role=presentation",
"style=width: 1228px; height: 120px;"
]
}
} |
| [activeRoute, overlays, pathname, startServices] | ||
| ); | ||
|
|
||
| // TODO: Remove this comment after testing |
There was a problem hiding this comment.
Tested, works as expected
| // TODO: Remove this comment after testing |
|
Thanks, everyone, for your help with checking this implementation. Due to a race condition between the custom implementation and the default one, we decided to add the possibility of enabling execution context tracking on demand instead of enabling it by default. You can review this implementation in the other PR. I will close this PR in favor of that one. |






Resolves #195778
🐞 Summary
This PR fixes missing executionContext in sharedux router by adding
SharedUXContextto theKibanaRenderContextProvider. (More context provided in this comment)After this change, we will have the route in the page name as well:
To ensure this logic does not have a negative impact on custom implementation in plugins and also possibly remove duplicate implementation that can be covered with this implementation, I added a temporary TODO comment to different plugins that have a custom implementation. I would appreciate it if someone from the team that owns those plugins would take a look at the usage of
useExecutionContextand ensure this logic works as expected after merging this PR according to the "How to test" section.It is worth mentioning that the APM customized execution context had worked as expected when I tested it with a static value.
APM test
🧪 How to test
This is the shared implementation that is provided by
KibanaRenderContextProviderThis logic will be visible in the
kibana-browserrequest on your page as shown below: (here is the code for setting pageName)For your plugin, please check the following:
useExecutionContextuseExecutionContextusage.// TODO: Remove this comment after testing.Plugin overview