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
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.
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
* 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
* 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
* Replace defaultValue with value
Added default value for size in text_style_picker
Made page_config select compressed
Added default values for props in appearance_form
Switched select to superselect in border_form
Refactored datacolumn
refactored simple_math_function
Fixed page_config
* Added an euispacer to border form
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?