It is not very useful to have:
* shardTimeout disabled if requestTimeout is enabled (means infinite es overruns)
* shardTimeout > requestTimeout if both enabled (means finite es overruns)
* shardTimeout < requestTimeout if both enabled (means partial results from es?)
The only option that really makes sense is to have shardTimeout === requestTimeout, so that's what I've done here.
* [ui/config] extract core config logic into vanilla JS UiSettingsClient
* [ui/config] stub the uiSettings individually for each test
* [ui/config] ensure that change events are emitted sync
* [uiSettings/batchSet] send request immediately, buffer when needed
Rather than buffering all writes and waiting 200ms before sending config
request to the uiSettings API, send updates as soon as they are received
but buffer updates that are received while another request is in
progress. This eliminates the 200ms delay and ensures that the server
receives requests from a single user in the correct order in the
unlikely event that many calls to `config.set()` are made in a very
short period of time.
* throw exeception when unable to migrate panel data
* catch migrate exception and show toast
* remove unneeded conversion to string
* fix jest test
* use forEach instead of map
* fix jest tests
* move toast and window.location change to constructor
* add more output
This will let us know if the filter is failing to be added on the
visualization before being saved.
* run 20x
* go back to single run
While in production, we use the `no-warnings` flag to prevent warnings from going to STDERR, and instead capture the warning events using our logger. Some warnings are helpful in debugging and/or identifying problems in production, like UnhandledPromiseRejection. Deprecation warnings are not an immediate problem, but an issue with upgrading to the next version of Node. These warnings will continue to be presented to developers, just not for production users.
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
The addition of the optional flag to disable leading wildcards inadvertently broke exists queries, which are accomplished in kuery with the fieldName:* syntax.
* advanced setting to control search request preference
* add header tests
* add sentince about caching to description
* change courier:setRequestPreference to list and add courier:customRequestPreference
* update setting text
* [kbn-dev-utils/procRunner] try using execa to avoid never-exitting procs
* [kbn-dev-utils/procRunner] don't listen for close event, rely on stdio streams ending
* separate implicit connection between app state panels and redux tree panels.
They are now two different objects. This will help pave the way to
removing so much apostate in view mode where it isn’t necessary
* remove console output
* fix tests and propagate dashboard title & description
* Clean up with review comments
* use reduce instead of map so the array becomes an object
* adding large_string_test (#17312)
* adding large_string_test
* removed a failing test, modified the existing one
* new line at the end of mappings.json
* removed the data.json file and also removed the navigateTo() and clickKibanaIndices() as createIndexPattern() takes care of it
* more modifications
* Test for Large number of Fields in Kibana. (#16237)
* test huge data
* new file for testing large number of fields
* testing large fields
* large_fields_test
* add the unload of es_archiver
* incorporated the changes in kibana.yml
* Revert "incorporated the changes in kibana.yml"
This reverts commit 8682121678.
* cleanup
* code simplification
* removed commented code
