* Revert "Remove MathJS Feature (#15652)"
This reverts commit 43bf1dbf4a.
* replacing math with tinymath
* pining version
* updating yarn.lock
* Fixing Prettier mis formatting
* fixing tests
* Adding unsupported agg back
* Adding functional test for math aggregation
- Fixing bad tests
- Resetting page for every test suite (why donesn't beforeEach work?)
- Adding test for Math agg
* Trying to fix values (due to inconsistencies in env)
* Change hashing algo of tagcloud rotations (#17597)
pulls in TimR's changes (#17594) to the hashing algorithm. This also replaces the reference screenshots to match the new rotations.
* Revert screenshot comparison tests to old threshold parameters (#17626)
Applies to Tagcloud. https://github.com/elastic/kibana/pull/17597 made them too strict, causing them to fail in CI.
Reverts change in c1ef3d892f
If an error is raised before the logger is setup, then the server will exit without any notice.
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
* [uiApp] replace uiApp.injectVars with server.injectUiAppVars()
* [server/injectUiAppVars] cleanup styling
* [server/injectUiAppVars] add test to verify injectUiAppVars merging
* [server/injectUiAppVars] describe what type of id we expect
* [uiExportTypes/uiApp] add removal error to proper location
* [uiApps/tests] avoid snapshots for undefined/{} values
* [kbn-es/cluster] fix promise handling to properly route success/failure
* [kbn-es/cli] catch errors that bubble to the CLI and log with a bit of style
* [kbn-es] fix promise handling when building from source
* [kbn-es] check for inverse of .stop() condition
* [kbn-es/cluster] resolve promise is cluster stops cleanly
* [kbn-es/cluster/start] reject if ES exits before starting
* [Server/Routes] organize status routes together with others
* remove flaky assertion
* move all the status stuff into src/server/status
* sugar on imports/exports
* fix lint/jest test
* comment and todo
* [dev/notice] add scripts for generating NOTICE.txt file
* [notice] react-resize-detector@0.6.0 was removed in b445389b79
* [notice] move notice text into relevant source
* [dev/notice] Generate NOTICE.txt file
* [jenkins] verify that notice.txt is up to date in CI
* [tasks/notice] update test to use new NOTICE.txt file
* [dev/notice] update company name in NOTICE.txt
* [notice/cli] exit with 0 when --help requested
* [notice/cli] add helpful logging
* [notice/cli] use --validate flag name instead
* [notice/cli] simplify NEWLINE_RE, ignore obscure line endings
* [utils/decode_geo_hash] fixup comment
* [utils/decode_geo_hash] remove useless comment
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>
