Skip to content

Commit 2845418

Browse files
[8.15] [Data Views] Mitigate issue where `has_es_data` check can cause Kibana to hang (#200476) (#201023)
# Backport This will backport the following commits from `main` to `8.15`: - [[Data Views] Mitigate issue where &#x60;has_es_data&#x60; check can cause Kibana to hang (#200476)](#200476) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Davis McPhee","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-20T18:52:47Z","message":"[Data Views] Mitigate issue where `has_es_data` check can cause Kibana to hang (#200476)\n\n## Summary\r\n\r\nThis PR mitigates an issue where the `has_es_data` check can hang when\r\nsome remote clusters are unresponsive, leaving users stuck in a loading\r\nstate in some apps (e.g. Discover and Dashboard) until the request times\r\nout. There are two main changes that help mitigate this issue:\r\n- The `resolve/cluster` request in the `has_es_data` endpoint has been\r\nsplit into two requests -- one for local data first, then another for\r\nremote data second. In cases where remote clusters are unresponsive but\r\nthere is data available in the local cluster, the remote check is never\r\nperformed and the check completes quickly. This likely resolves the\r\nmajority of cases and is also likely faster in general than checking\r\nboth local and remote clusters in a single request.\r\n- In cases where there is no local data and the remote `resolve/cluster`\r\nrequest hangs, a new `data_views.hasEsDataTimeout` config has been added\r\nto `kibana.yml` (defaults to 5 seconds) to abort the request after a\r\nshort delay. This scenario is handled in the front end by displaying an\r\nerror toast to the user informing them of the issue, and assuming there\r\nis data available to avoid blocking them. When this occurs, a warning is\r\nalso logged to the Kibana server logs.\r\n\r\n![CleanShot 2024-11-18 at 23 47\r\n34@2x](https://github.com/user-attachments/assets/6ea14869-b6b6-4d89-a90c-8150d6e6b043)\r\n\r\nFixes #200280.\r\n\r\n### Notes\r\n- Modifying the existing version of the `has_es_data` endpoint in this\r\nway should be backward compatible since the behaviour should remain\r\nunchanged from before when the client and server versions don't match\r\n(please validate if this seems accurate during review).\r\n- For a long term fix, the ES team is investigating the issue with\r\n`resolve/cluster` and will aim to have it behave like `resolve/index`,\r\nwhich fails quickly when remote clusters are unresponsive. They may also\r\nimplement other mitigations like a configurable timeout in ES:\r\nhttps://github.com/elastic/elasticsearch/issues/114020. The purpose of\r\nthis PR is to provide an immediate solution in Kibana that mitigates the\r\nissue as much as possible.\r\n- If ES ends up providing another performant method for checking if\r\nindices exist instead of `resolve/cluster`, Kibana should migrate to\r\nthat. More details in\r\nhttps://github.com/elastic/elasticsearch/issues/112307.\r\n\r\n### Testing notes\r\n\r\nTo reproduce the issue locally, follow these steps:\r\n- Follow [these\r\ninstructions](https://gist.github.com/lukasolson/d0861aa3e6ee476ac8dd7189ed476756)\r\nto set up a local CCS environment.\r\n- Stop the remote cluster process.\r\n- Use Netcat on the remote cluster port to listen to requests but not\r\nrespond (e.g. on macOS: `nc -l 9600`), simulating an unresponsive\r\ncluster. See elastic/elasticsearch#32678 for\r\nmore context.\r\n- Navigate to Discover and observe that the `has_es_data` request hangs.\r\nWhen testing in this PR branch, the request will only wait for 5 seconds\r\nbefore assuming data exists and displaying a toast.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added follows [EUI's writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\r\nsentence case text and includes [i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n- [ ]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas added for features that require explanation or tutorials\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n- [ ] If a plugin configuration key changed, check if it needs to be\r\nallowlisted in the cloud and added to the [docker\r\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\r\n- [x] This was checked for breaking HTTP API changes, and any breaking\r\nchanges have been approved by the breaking-change committee. The\r\n`release_note:breaking` label should be applied in these situations.\r\n- [ ] [Flaky Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\r\nused on any tests changed\r\n- [x] The PR description includes the appropriate Release Notes section,\r\nand the correct `release_node:*` label is applied per the\r\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"96fd4b682b77f6c1d6d1c6ab0742462d9e9d2589","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","v9.0.0","Team:DataDiscovery","backport:prev-major"],"title":"[Data Views] Mitigate issue where `has_es_data` check can cause Kibana to hang","number":200476,"url":"https://github.com/elastic/kibana/pull/200476","mergeCommit":{"message":"[Data Views] Mitigate issue where `has_es_data` check can cause Kibana to hang (#200476)\n\n## Summary\r\n\r\nThis PR mitigates an issue where the `has_es_data` check can hang when\r\nsome remote clusters are unresponsive, leaving users stuck in a loading\r\nstate in some apps (e.g. Discover and Dashboard) until the request times\r\nout. There are two main changes that help mitigate this issue:\r\n- The `resolve/cluster` request in the `has_es_data` endpoint has been\r\nsplit into two requests -- one for local data first, then another for\r\nremote data second. In cases where remote clusters are unresponsive but\r\nthere is data available in the local cluster, the remote check is never\r\nperformed and the check completes quickly. This likely resolves the\r\nmajority of cases and is also likely faster in general than checking\r\nboth local and remote clusters in a single request.\r\n- In cases where there is no local data and the remote `resolve/cluster`\r\nrequest hangs, a new `data_views.hasEsDataTimeout` config has been added\r\nto `kibana.yml` (defaults to 5 seconds) to abort the request after a\r\nshort delay. This scenario is handled in the front end by displaying an\r\nerror toast to the user informing them of the issue, and assuming there\r\nis data available to avoid blocking them. When this occurs, a warning is\r\nalso logged to the Kibana server logs.\r\n\r\n![CleanShot 2024-11-18 at 23 47\r\n34@2x](https://github.com/user-attachments/assets/6ea14869-b6b6-4d89-a90c-8150d6e6b043)\r\n\r\nFixes #200280.\r\n\r\n### Notes\r\n- Modifying the existing version of the `has_es_data` endpoint in this\r\nway should be backward compatible since the behaviour should remain\r\nunchanged from before when the client and server versions don't match\r\n(please validate if this seems accurate during review).\r\n- For a long term fix, the ES team is investigating the issue with\r\n`resolve/cluster` and will aim to have it behave like `resolve/index`,\r\nwhich fails quickly when remote clusters are unresponsive. They may also\r\nimplement other mitigations like a configurable timeout in ES:\r\nhttps://github.com/elastic/elasticsearch/issues/114020. The purpose of\r\nthis PR is to provide an immediate solution in Kibana that mitigates the\r\nissue as much as possible.\r\n- If ES ends up providing another performant method for checking if\r\nindices exist instead of `resolve/cluster`, Kibana should migrate to\r\nthat. More details in\r\nhttps://github.com/elastic/elasticsearch/issues/112307.\r\n\r\n### Testing notes\r\n\r\nTo reproduce the issue locally, follow these steps:\r\n- Follow [these\r\ninstructions](https://gist.github.com/lukasolson/d0861aa3e6ee476ac8dd7189ed476756)\r\nto set up a local CCS environment.\r\n- Stop the remote cluster process.\r\n- Use Netcat on the remote cluster port to listen to requests but not\r\nrespond (e.g. on macOS: `nc -l 9600`), simulating an unresponsive\r\ncluster. See elastic/elasticsearch#32678 for\r\nmore context.\r\n- Navigate to Discover and observe that the `has_es_data` request hangs.\r\nWhen testing in this PR branch, the request will only wait for 5 seconds\r\nbefore assuming data exists and displaying a toast.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added follows [EUI's writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\r\nsentence case text and includes [i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n- [ ]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas added for features that require explanation or tutorials\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n- [ ] If a plugin configuration key changed, check if it needs to be\r\nallowlisted in the cloud and added to the [docker\r\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\r\n- [x] This was checked for breaking HTTP API changes, and any breaking\r\nchanges have been approved by the breaking-change committee. The\r\n`release_note:breaking` label should be applied in these situations.\r\n- [ ] [Flaky Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\r\nused on any tests changed\r\n- [x] The PR description includes the appropriate Release Notes section,\r\nand the correct `release_node:*` label is applied per the\r\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"96fd4b682b77f6c1d6d1c6ab0742462d9e9d2589"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/200476","number":200476,"mergeCommit":{"message":"[Data Views] Mitigate issue where `has_es_data` check can cause Kibana to hang (#200476)\n\n## Summary\r\n\r\nThis PR mitigates an issue where the `has_es_data` check can hang when\r\nsome remote clusters are unresponsive, leaving users stuck in a loading\r\nstate in some apps (e.g. Discover and Dashboard) until the request times\r\nout. There are two main changes that help mitigate this issue:\r\n- The `resolve/cluster` request in the `has_es_data` endpoint has been\r\nsplit into two requests -- one for local data first, then another for\r\nremote data second. In cases where remote clusters are unresponsive but\r\nthere is data available in the local cluster, the remote check is never\r\nperformed and the check completes quickly. This likely resolves the\r\nmajority of cases and is also likely faster in general than checking\r\nboth local and remote clusters in a single request.\r\n- In cases where there is no local data and the remote `resolve/cluster`\r\nrequest hangs, a new `data_views.hasEsDataTimeout` config has been added\r\nto `kibana.yml` (defaults to 5 seconds) to abort the request after a\r\nshort delay. This scenario is handled in the front end by displaying an\r\nerror toast to the user informing them of the issue, and assuming there\r\nis data available to avoid blocking them. When this occurs, a warning is\r\nalso logged to the Kibana server logs.\r\n\r\n![CleanShot 2024-11-18 at 23 47\r\n34@2x](https://github.com/user-attachments/assets/6ea14869-b6b6-4d89-a90c-8150d6e6b043)\r\n\r\nFixes #200280.\r\n\r\n### Notes\r\n- Modifying the existing version of the `has_es_data` endpoint in this\r\nway should be backward compatible since the behaviour should remain\r\nunchanged from before when the client and server versions don't match\r\n(please validate if this seems accurate during review).\r\n- For a long term fix, the ES team is investigating the issue with\r\n`resolve/cluster` and will aim to have it behave like `resolve/index`,\r\nwhich fails quickly when remote clusters are unresponsive. They may also\r\nimplement other mitigations like a configurable timeout in ES:\r\nhttps://github.com/elastic/elasticsearch/issues/114020. The purpose of\r\nthis PR is to provide an immediate solution in Kibana that mitigates the\r\nissue as much as possible.\r\n- If ES ends up providing another performant method for checking if\r\nindices exist instead of `resolve/cluster`, Kibana should migrate to\r\nthat. More details in\r\nhttps://github.com/elastic/elasticsearch/issues/112307.\r\n\r\n### Testing notes\r\n\r\nTo reproduce the issue locally, follow these steps:\r\n- Follow [these\r\ninstructions](https://gist.github.com/lukasolson/d0861aa3e6ee476ac8dd7189ed476756)\r\nto set up a local CCS environment.\r\n- Stop the remote cluster process.\r\n- Use Netcat on the remote cluster port to listen to requests but not\r\nrespond (e.g. on macOS: `nc -l 9600`), simulating an unresponsive\r\ncluster. See elastic/elasticsearch#32678 for\r\nmore context.\r\n- Navigate to Discover and observe that the `has_es_data` request hangs.\r\nWhen testing in this PR branch, the request will only wait for 5 seconds\r\nbefore assuming data exists and displaying a toast.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added follows [EUI's writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\r\nsentence case text and includes [i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n- [ ]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas added for features that require explanation or tutorials\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n- [ ] If a plugin configuration key changed, check if it needs to be\r\nallowlisted in the cloud and added to the [docker\r\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\r\n- [x] This was checked for breaking HTTP API changes, and any breaking\r\nchanges have been approved by the breaking-change committee. The\r\n`release_note:breaking` label should be applied in these situations.\r\n- [ ] [Flaky Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\r\nused on any tests changed\r\n- [x] The PR description includes the appropriate Release Notes section,\r\nand the correct `release_node:*` label is applied per the\r\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"96fd4b682b77f6c1d6d1c6ab0742462d9e9d2589"}}]}] BACKPORT--> --------- Co-authored-by: Davis McPhee <[email protected]>
1 parent 833d557 commit 2845418

File tree

11 files changed

+590
-29
lines changed

11 files changed

+590
-29
lines changed

src/plugins/data_views/common/constants.ts

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -78,3 +78,12 @@ export const EXISTING_INDICES_PATH = '/internal/data_views/_existing_indices';
7878
export const DATA_VIEWS_FIELDS_EXCLUDED_TIERS = 'data_views:fields_excluded_data_tiers';
7979

8080
export const DEFAULT_DATA_VIEW_ID = 'defaultIndex';
81+
82+
/**
83+
* Valid `failureReason` attribute values for `has_es_data` API error responses
84+
*/
85+
export enum HasEsDataFailureReason {
86+
localDataTimeout = 'local_data_timeout',
87+
remoteDataTimeout = 'remote_data_timeout',
88+
unknown = 'unknown',
89+
}

src/plugins/data_views/common/index.ts

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,7 @@ export {
1212
META_FIELDS,
1313
DATA_VIEW_SAVED_OBJECT_TYPE,
1414
MAX_DATA_VIEW_FIELD_DESCRIPTION_LENGTH,
15+
HasEsDataFailureReason,
1516
} from './constants';
1617

1718
export { LATEST_VERSION } from './content_management/v1/constants';

src/plugins/data_views/common/types.ts

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -570,4 +570,5 @@ export interface ClientConfigType {
570570
scriptedFieldsEnabled?: boolean;
571571
dataTiersExcludedForFields?: string;
572572
fieldListCachingEnabled?: boolean;
573+
hasEsDataTimeout: number;
573574
}

src/plugins/data_views/public/services/has_data.test.ts

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@
99
import { coreMock } from '@kbn/core/public/mocks';
1010

1111
import { HasData } from './has_data';
12+
import { HttpFetchError } from '@kbn/core-http-browser-internal/src/http_fetch_error';
1213

1314
describe('when calling hasData service', () => {
1415
describe('hasDataView', () => {
@@ -169,6 +170,78 @@ describe('when calling hasData service', () => {
169170

170171
expect(await response).toBe(false);
171172
});
173+
174+
it('should return true and show an error toast when checking for remote cluster data times out', async () => {
175+
const coreStart = coreMock.createStart();
176+
const http = coreStart.http;
177+
178+
// Mock getIndices
179+
const spy = jest.spyOn(http, 'get').mockImplementation(() =>
180+
Promise.reject(
181+
new HttpFetchError(
182+
'Timeout while checking for Elasticsearch data',
183+
'TimeoutError',
184+
new Request(''),
185+
undefined,
186+
{
187+
statusCode: 504,
188+
message: 'Timeout while checking for Elasticsearch data',
189+
attributes: {
190+
failureReason: 'remote_data_timeout',
191+
},
192+
}
193+
)
194+
)
195+
);
196+
const hasData = new HasData();
197+
const hasDataService = hasData.start(coreStart, true);
198+
const response = hasDataService.hasESData();
199+
200+
expect(spy).toHaveBeenCalledTimes(1);
201+
expect(await response).toBe(true);
202+
expect(coreStart.notifications.toasts.addDanger).toHaveBeenCalledTimes(1);
203+
expect(coreStart.notifications.toasts.addDanger).toHaveBeenCalledWith({
204+
title: 'Remote cluster timeout',
205+
text: 'Checking for data on remote clusters timed out. One or more remote clusters may be unavailable.',
206+
});
207+
});
208+
209+
it('should return true and not show an error toast when checking for remote cluster data times out, but onRemoteDataTimeout is overridden', async () => {
210+
const coreStart = coreMock.createStart();
211+
const http = coreStart.http;
212+
213+
// Mock getIndices
214+
const responseBody = {
215+
statusCode: 504,
216+
message: 'Timeout while checking for Elasticsearch data',
217+
attributes: {
218+
failureReason: 'remote_data_timeout',
219+
},
220+
};
221+
const spy = jest
222+
.spyOn(http, 'get')
223+
.mockImplementation(() =>
224+
Promise.reject(
225+
new HttpFetchError(
226+
'Timeout while checking for Elasticsearch data',
227+
'TimeoutError',
228+
new Request(''),
229+
undefined,
230+
responseBody
231+
)
232+
)
233+
);
234+
const hasData = new HasData();
235+
const hasDataService = hasData.start(coreStart, true);
236+
const onRemoteDataTimeout = jest.fn();
237+
const response = hasDataService.hasESData({ onRemoteDataTimeout });
238+
239+
expect(spy).toHaveBeenCalledTimes(1);
240+
expect(await response).toBe(true);
241+
expect(coreStart.notifications.toasts.addDanger).not.toHaveBeenCalled();
242+
expect(onRemoteDataTimeout).toHaveBeenCalledTimes(1);
243+
expect(onRemoteDataTimeout).toHaveBeenCalledWith(responseBody);
244+
});
172245
});
173246

174247
describe('resolve/cluster not available', () => {

src/plugins/data_views/public/services/has_data.ts

Lines changed: 49 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -7,10 +7,22 @@
77
*/
88

99
import { CoreStart, HttpStart } from '@kbn/core/public';
10-
import { DEFAULT_ASSETS_TO_IGNORE } from '../../common';
10+
import { IHttpFetchError, ResponseErrorBody, isHttpFetchError } from '@kbn/core-http-browser';
11+
import { isObject } from 'lodash';
12+
import { i18n } from '@kbn/i18n';
13+
import { DEFAULT_ASSETS_TO_IGNORE, HasEsDataFailureReason } from '../../common';
1114
import { HasDataViewsResponse, IndicesViaSearchResponse } from '..';
1215
import { IndicesResponse, IndicesResponseModified } from '../types';
1316

17+
export interface HasEsDataParams {
18+
/**
19+
* Callback to handle the case where checking for remote data times out.
20+
* If not provided, the default behavior is to show a toast notification.
21+
* @param body The error response body
22+
*/
23+
onRemoteDataTimeout?: (body: ResponseErrorBody) => void;
24+
}
25+
1426
export class HasData {
1527
private removeAliases = (source: IndicesResponseModified): boolean => !source.item.indices;
1628

@@ -37,28 +49,55 @@ export class HasData {
3749
return hasLocalESData;
3850
};
3951

40-
const hasESDataViaResolveCluster = async () => {
52+
const hasESDataViaResolveCluster = async (
53+
onRemoteDataTimeout: (body: ResponseErrorBody) => void
54+
) => {
4155
try {
4256
const { hasEsData } = await http.get<{ hasEsData: boolean }>(
4357
'/internal/data_views/has_es_data',
44-
{
45-
version: '1',
46-
}
58+
{ version: '1' }
4759
);
60+
4861
return hasEsData;
4962
} catch (e) {
63+
if (
64+
this.isResponseError(e) &&
65+
e.body?.statusCode === 504 &&
66+
e.body?.attributes?.failureReason === HasEsDataFailureReason.remoteDataTimeout
67+
) {
68+
onRemoteDataTimeout(e.body);
69+
70+
// In the case of a remote cluster timeout,
71+
// we can't be sure if there is data or not,
72+
// so just assume there is
73+
return true;
74+
}
75+
5076
// fallback to previous implementation
5177
return hasESDataViaResolveIndex();
5278
}
5379
};
5480

81+
const showRemoteDataTimeoutToast = () =>
82+
core.notifications.toasts.addDanger({
83+
title: i18n.translate('dataViews.hasData.remoteDataTimeoutTitle', {
84+
defaultMessage: 'Remote cluster timeout',
85+
}),
86+
text: i18n.translate('dataViews.hasData.remoteDataTimeoutText', {
87+
defaultMessage:
88+
'Checking for data on remote clusters timed out. One or more remote clusters may be unavailable.',
89+
}),
90+
});
91+
5592
return {
5693
/**
5794
* Check to see if ES data exists
5895
*/
59-
hasESData: async (): Promise<boolean> => {
96+
hasESData: async ({
97+
onRemoteDataTimeout = showRemoteDataTimeoutToast,
98+
}: HasEsDataParams = {}): Promise<boolean> => {
6099
if (callResolveCluster) {
61-
return hasESDataViaResolveCluster();
100+
return hasESDataViaResolveCluster(onRemoteDataTimeout);
62101
}
63102
return hasESDataViaResolveIndex();
64103
},
@@ -81,6 +120,9 @@ export class HasData {
81120

82121
// ES Data
83122

123+
private isResponseError = (e: Error): e is IHttpFetchError<ResponseErrorBody> =>
124+
isHttpFetchError(e) && isObject(e.body) && 'message' in e.body && 'statusCode' in e.body;
125+
84126
private responseToItemArray = (response: IndicesResponse): IndicesResponseModified[] => {
85127
const { indices = [], aliases = [] } = response;
86128
const source: IndicesResponseModified[] = [];

src/plugins/data_views/server/index.ts

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -46,7 +46,6 @@ const configSchema = schema.object({
4646
schema.boolean({ defaultValue: false }),
4747
schema.never()
4848
),
49-
5049
dataTiersExcludedForFields: schema.conditional(
5150
schema.contextRef('serverless'),
5251
true,
@@ -59,6 +58,7 @@ const configSchema = schema.object({
5958
schema.boolean({ defaultValue: false }),
6059
schema.boolean({ defaultValue: true })
6160
),
61+
hasEsDataTimeout: schema.number({ defaultValue: 5000 }),
6262
});
6363

6464
type ConfigType = TypeOf<typeof configSchema>;

src/plugins/data_views/server/plugin.ts

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -62,9 +62,11 @@ export class DataViewsServerPlugin
6262

6363
registerRoutes({
6464
http: core.http,
65+
logger: this.logger,
6566
getStartServices: core.getStartServices,
6667
isRollupsEnabled: () => this.rollupsEnabled,
6768
dataViewRestCounter,
69+
hasEsDataTimeout: config.hasEsDataTimeout,
6870
});
6971

7072
expressions.registerFunction(getIndexPatternLoad({ getStartServices: core.getStartServices }));

0 commit comments

Comments
 (0)