Fixes the missing y-axis description for rare charts in the form of y-axis event distribution split by {{fieldName}}. The intention is to briefly clarify that the type of chart is different than the other ones which have a count or metric based y-axis. This text is in addition to the text provided (but hidden without hovering) in the info icon tooltip.
In certain cases tickInterval mistakenly could end up being negative which made getTickValues() run into a call stack size exception. This PR fixes it by a) adding a check to getTickValues() that interval must not be 0 or smaller and b) changing the way the tickInterval is determined in the Anomaly Explorer Charts.
This commit does three things:
0. This fixes the instructions for interacting with the heartbeat service, which is called `heartbeat-elastic` not `heartbeat`
1. This removes some extraneous text that should be reserved for the subsequent section.
2. This makes the instructions for creating a monitor more explicit
I noticed the following message while watching the build output:
```
00:33:19.131 │ info [kibana] > /var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-x-pack/install/kibana/bin/kibana --optimize.useBundleCache=true --env.name=development --logging.json=false --server.port=5620 --optimize.watchPort=5630 --optimize.watchPrebuild=true --status.allowAnonymous=true --elasticsearch.url=http://elastic:changeme@localhost:9220 --elasticsearch.username=elastic --elasticsearch.password=changeme --server.uuid=5b2de169-2785-441b-ae8c-186a1936b17d --xpack.xpack_main.telemetry.enabled=false --xpack.security.encryptionKey="wuGNaIhoMpk5sO4UBxgr3NyW1sFcLgIf" --optimize.enabled=true --xpack.reporting.capture.browser.type=chromium --xpack.spaces.enabled=false
00:33:38.533 │ proc [kibana] log [23:20:25.923] [info][optimize] Optimizing and caching bundles for ml, stateSessionStorageRedirect, status_page, timelion, graph, monitoring, login, logout, dashboardViewer, apm, canvas, infra and kibana. This may take a few minutes
00:34:12.650 │ proc [kibana] [BABEL] Note: The code generator has deoptimised the styling of "/var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-x-pack/install/kibana/node_modules/x-pack/plugins/infra/node_modules/lodash/lodash.js" as it exceeds the max of "500KB".
00:36:11.346 │ proc [kibana] log [23:22:58.721] [info][optimize] Optimization of bundles for ml, stateSessionStorageRedirect, status_page, timelion, graph, monitoring, login, logout, dashboardViewer, apm, canvas, infra and kibana complete in 152.79 seconds
```
The "code generator has deoptimised" line specifically raised a red flag as babel shouldn't be running on node_modules. We have admittedly weak regular expressions in two places to enforce this. The first is in 49071132c3/src/setup_node_env/babel_register/register.js (L42), which I verified matched `node_modules` directories within the `node_modules/x-pack` directory, but the other is 49071132c3/src/optimize/base_optimizer.js (L152-L154) which does not. It only excludes files from babel in webpack if they are within a node_modules directory that is a direct child of `node_modules/xpack`, but with InfraOps and Canvas we now have node_module directories at `plugins/*/node_modules`.
This should probably be fixed by preventing plugins from installing their own node_modules, but since that would involve upgrading/moving plugins between major versions of dependencies like lodash that's somewhat impractical from where I stand, so instead I've just updated the webpack module rule to exclude any `node_modules/xpack/**/node_modules` directory.
In order to support esjs apiVersion 6.5 we need to upgrade to the newly released version of elasticsearch-js. Bumping makelogs allowed us to keep only one version of the elasticsearch module installed.
* [kbn-datemath][parseEsInterval] improve types slightly
* [kbn-datemath][vis/leastCommonInterval] make types more precise
* [ui/leastCommonInterval] fix bug in finding same types
* add back valid test
* Revert "Reporting cookies (#24177)"
This reverts commit 9f4ec18000.
* Take 2
* Adding comment
* Better escaping and encoding for use in eval
* Checking for an empty string also
* Fixing session test
Instead of immediately throwing an error if a watch Action is invalid (an email for example), there is now an `option` object that we can pass to the `fromUpstreamJson()` method and receive back any error that might exist in a Watch.
The Watch has a new "watchErrors" property to display configuration error in the UI.
fixes#20305fixes#20970
* Fixes rare cases where KibanaLink will be loaded outside of React context and requires no redux connect dependency
* Fixes tests for updated Kibana link component
* Removes obsolete snapshot
* Updates waterfall item design for timeline rows
* Adjusts span and tx flyouts and updates tooltips to EUI
* Heading size fixes and clean up
* Updates tooltip snapshots
* Review tweaks and snapshot updates
* Revert experiment :)
Co-Authored-By: jasonrhodes <jason.matthew.rhodes@gmail.com>
* Fixes bug with v1 waterfall state
* Fixes bug with timeline bar height
* Updates snapshot tests
* Updated test so it doesn't mount and rely on EUI makeId() which is non-deterministic per test run
Replaces https://github.com/elastic/kibana/pull/23301
Closes https://github.com/elastic/kibana/issues/23080
---
This is a minimal threading implementation for Canvas. There's still a lot to be done to make this concept great, but this is a start.
What it does:
- Creates a server side abstraction on top of the interpreter
- Determines where to send the expression by checking the first function to be run
- Loads common functions in a separate worker thread on the server.
- Routes to a single forked worker (thread), the main thread (server), or the browser (browser), in that order
- Defers back to the router when a function isn't found. Fails if the function isn't found in any of the above 3 environments
- Times out the worker if it takes too long, and respawns it as needed.
- Simplifies the error dialog to remove the stack.
What is does not.:
- Round robin a pool of workers
- Queue. If one expression in the threaded env fails then anything sent to it in the meantime will fail. The upstream environment handles managing timeouts. I think this would only make sense todo with a pool.
- Client side. This doesn't implement web workers, but we could use roughly the same architecture.
- Implement a specific, pluggable `worker` environment on the server. Right now it's just common functions, so plugin authors will always end up in a thread if they put their function in the common directory.
What I don't like:
- The socketProvider code. This was reused across the server & browser, but now that it's only used in the browser there's no good reason for the abstraction
- The serialize/deserialize stuff feels messy. Do we really need serialization?
* Update output file format for i18n_check tool
* Update i18n engine to work with new format
* Update tests
* Fix UI bootstrap test
* Update loader tests and fix getTranslationsByLocale function
* Fix messages passing to IntlProvider
* Update messages interface
* Resolve comments
* Resolve comment
