[9.4] [Lens as code] Fix metric trendline (#264777)#264888
[9.4] [Lens as code] Fix metric trendline (#264777)#264888kibanamachine merged 1 commit intoelastic:9.4from
Conversation
## Summary This PR fixes the missing trendline for metric when creating the chart from the API. There where multiple problems connected to that: - the histogram column definition wasn't a date_histogram operation but the `newPrimaryColumns` (the metric operation) - the `columnOrder` was wrong and caused the expression to not pick up property the idMap (datatable columns to accessord ids) - the `references` array wasn't populated with the dataview references used in the trendline fix elastic#251620 (cherry picked from commit dbc7ea0)
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
There was a problem hiding this comment.
Scout Test Review: found 2 issues. See inline comments for details.
Share feedback in the #appex-qa channel.
Posted via Macroscope — Scout Test Review
| const DASHBOARD_API_VERSION = '2023-10-31'; | ||
|
|
||
| const LOGSTASH_TIME_RANGE = { | ||
| from: '2015-09-19T06:31:44.000Z', | ||
| to: '2015-09-23T18:31:44.000Z', | ||
| }; | ||
|
|
||
| function withSpace(path: string, spaceId: string): string { | ||
| return `/s/${spaceId}${path}`; | ||
| } | ||
|
|
||
| async function createDashboard(client: KbnClient, body: unknown, spaceId: string): Promise<string> { | ||
| const response = await client.request<unknown>({ | ||
| method: 'POST', |
There was a problem hiding this comment.
The createDashboard helper duplicates the dashboard-creation pattern already in esql_timeseries_dashboard_api.spec.ts (createDashboardWithLensPanel). Both hit the same API with the same version header.
See details
Consider extracting a shared createDashboard(client, body, spaceId) into the existing fixtures/helpers.ts so both spec files (and future ones) reuse the same helper. This keeps the API path, version header, and status assertion in one place.
// fixtures/helpers.ts
export async function createDashboard(
client: KbnClient,
body: unknown,
spaceId: string
): Promise<string> {
const response = await client.request<unknown>({
method: 'POST',
path: `/s/${spaceId}/api/dashboards`,
body,
headers: { 'elastic-api-version': '2023-10-31' },
});
if (response.status !== 200 && response.status !== 201) {
throw new Error(`Dashboard create failed: ${response.status}`);
}
const { id } = response.data as Record<string, unknown>;
if (typeof id !== 'string' || id.length === 0) {
throw new Error('Dashboard create: expected a non-empty id');
}
return id;
}Then both spec files import createDashboard from '../fixtures'.
Posted via Macroscope — Scout Test Review
| await expect(page.getByTestId('mtrVis')).toBeVisible(); | ||
| await expect(page.locator('.echSingleMetricSparkline')).toBeVisible(); |
There was a problem hiding this comment.
.echSingleMetricSparkline is a CSS class from @elastic/charts — no data-test-subj exists for it today. Raw class selectors can break silently when the library updates class names.
See details
The existing FTR page object (lens_page.ts) uses the same CSS class, so this isn't new risk. However, the Scout best practice is to prefer data-test-subj, and if one is missing, to add it in source code.
Consider scoping the CSS selector under the mtrVis test-subj container so it's at least more resilient:
const metricVis = page.getByTestId('mtrVis');
await expect(metricVis).toBeVisible();
await expect(metricVis.locator('.echSingleMetricSparkline')).toBeVisible();Longer-term, a data-test-subj on the sparkline wrapper in @elastic/charts would make all these selectors more stable.
Posted via Macroscope — Scout Test Review
2 participants
Backport
This will backport the following commits from
mainto9.4:Questions ?
Please refer to the Backport tool documentation