Skip to content

Commit dbe6c7b

Browse files
[8.x] [Data Views] Mitigate issue where `has_es_data` check can cause Kibana to hang (#200476) (#201025)
# Backport This will backport the following commits from `main` to `8.x`: - [[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 20cbae5 commit dbe6c7b

File tree

11 files changed

+582
-29
lines changed

11 files changed

+582
-29
lines changed

src/plugins/data_views/common/constants.ts

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

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

src/plugins/data_views/common/index.ts

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

1819
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
@@ -571,4 +571,5 @@ export interface ClientConfigType {
571571
scriptedFieldsEnabled?: boolean;
572572
dataTiersExcludedForFields?: string;
573573
fieldListCachingEnabled?: boolean;
574+
hasEsDataTimeout: number;
574575
}

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

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

1212
import { HasData } from './has_data';
13+
import { HttpFetchError } from '@kbn/core-http-browser-internal/src/http_fetch_error';
1314

1415
describe('when calling hasData service', () => {
1516
describe('hasDataView', () => {
@@ -170,6 +171,78 @@ describe('when calling hasData service', () => {
170171

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

175248
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
@@ -8,10 +8,22 @@
88
*/
99

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

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

@@ -38,28 +50,55 @@ export class HasData {
3850
return hasLocalESData;
3951
};
4052

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

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

83122
// ES Data
84123

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

src/plugins/data_views/server/index.ts

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,6 @@ const configSchema = schema.object({
4747
schema.boolean({ defaultValue: false }),
4848
schema.never()
4949
),
50-
5150
dataTiersExcludedForFields: schema.conditional(
5251
schema.contextRef('serverless'),
5352
true,
@@ -60,6 +59,7 @@ const configSchema = schema.object({
6059
schema.boolean({ defaultValue: false }),
6160
schema.boolean({ defaultValue: true })
6261
),
62+
hasEsDataTimeout: schema.number({ defaultValue: 5000 }),
6363
});
6464

6565
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
@@ -63,9 +63,11 @@ export class DataViewsServerPlugin
6363

6464
registerRoutes({
6565
http: core.http,
66+
logger: this.logger,
6667
getStartServices: core.getStartServices,
6768
isRollupsEnabled: () => this.rollupsEnabled,
6869
dataViewRestCounter,
70+
hasEsDataTimeout: config.hasEsDataTimeout,
6971
});
7072

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

0 commit comments

Comments
 (0)