This is a pre-cursor to https://github.com/elastic/kibana/issues/58529
I realized a bit ago that we weren't making quite enough info available
in the action parameter templating that happens when alerts schedule
actions to execute. Missing were alert name, tags, and spaceId.
For the index threshold alert, I had added them to it's context, but
then every other action would have to do the same if they also
wanted those values.
So I added these as additional top-level variables that can be
used in templates, along with the alert id, alert instance id,
context, and state. The other bits in RawAlert didn't seem
that interesting, to be used as an action parameter.
* scaffolding and notes.md
* add skeleton event generator to kibana
* add optional entityID param to generateEvent
* add tree generation
* add tests
* working tests
* fix up tests
* fix linting
* fix event types
* make process parent types consistent
* make generator match types
* move test resolver node out of common types
* fix random string generation
* fix typecheck errors
* remove extraneous stuff
* address PR comments
* add test for full resolver tree
* cleanup
* make tests clearer
* add seedrandom to endpoint plugin. contains DONOTMERGE example code
* remove robs test
* start replacing random with seedrandom
* use seeded random for uuidv4
* separate out IP randomization
* typecheck fixes
Co-authored-by: oatkiller <robert.austin@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Convert our manual throwing of TypeError to a custom Error
Throwing a TypeError meant that our manual errors were indistinguishable
from, say, trying to invoke a method on undefined. This adds a custom
error, BadRequestError, that disambiguates that situation.
* Present API Error messages to the user
With Core's new HTTP client, an unsuccessful API call will raise an
error containing the body of the response it received. In the case of
SIEM endpoints, this will include a useful error message with
potentially more specificity than e.g. 'Internal Server Error'.
This adds a type predicate to check for such errors, and adds a handling
case in our errorToToaster handler.
If the error does not contain our SIEM-specific message, it will fall
through as normal and the general error.message will be displayed in the
toaster.
* Remove unnecessary use of throwIfNotOk in our client API calls
The new HTTP client raises an error on a 4xx or 5xx response, so there
should not be a case where throwIfNotOk is actually going to throw an
error.
The established pattern on the frontend is to catch errors at the call
site and handle them appropriately, so I'm mainly just verifying that
these are caught where they're used, now.
* Move errorToToaster and ToasterError to general location
These were living in ML since that's where they originated. However, we
have need of it (and already use it) elsewhere.
The basic pattern for error handling on the frontend is:
1) API call throws error
2) caller catches error and dispatches a toast
throwIfNotOk is meant to convert the error into a useful message in 1).
We currently use both errorToToaster and displayErrorToast to display
that in a toaster in 2)
Now that errorToToaster handles a few different types of errors, and
throwIfNotOk is going to be bypassed due to the new client behavior of
throwing on error, we're going to start consolidating on:
1) Api call throws error
2) caller catches error and passes it to errorToToaster
* Refactor Rules API functions to not use throwIfNotOk
* Ensures that all callers of these methods properly catch errors
* Updates error toasterification to use errorToToaster
* Simplifies tests now that we mainly just invoke the http client and
return the result.
throwIfNotOk is not being used in the majority of cases, as the client
raises an error and bypasses that call.
The few cases this might break are where we return a 200 but have errors
within the response. Whether throwIfNotOk handled this or not, I'll need
a simpler helper to accomplish the same behavior.
* Define a type for our BulkRule responses
These can be an array of errors OR rules; typing it as such forces
downstream to deal with both. enableRules was being handled correctly
with the bucketing helper, and TS has confirmed the rest are as well.
This obviates the need to raise from our API calls, as bulk errors are
recoverable and we want to both a) continue on with any successful rules
and b) handle the errors as necessary. This is highly dependent on the
caller and so we can't/shouldn't handle it here.
* Address case where bulk rules errors were not handled
I'm not sure that we're ever using this non-dispatch version, but it was
throwing a type error. Will bring it up in review.
* Remove more throwIfNotOk uses from API calls
These are unneeded as an error response will already throw an error to
be handled at the call site.
* Display an error toaster on newsfeed fetch failure
* Remove dead code
This was left over as a result of #56261
* Remove throwIfNotOk from case API calls
Again, not needed because the client already throws.
* Update use_get_tags for NP
* Gets rid of throwIfNotOK usage
* uses core http fetch
* Remove throwIfNotOk from signals API
* Remove throwIfNotOk
This served the same purpose as errorToToaster, but in a less robust
way. All usages have been replaced, so now we say goodbye.
* Remove custom errors in favor of KibanaApiError and isApiError type predicate
There was no functional difference between these two code paths, and
removing these custom errors allowed us to delete a bunch of associated
code as well..
* Fix test failures
These were mainly related to my swapping any remaining fetch calls with
the core router as good kibana denizens should :salute:
* Replace use of core mocks with our simpler local ones
This is enough to get our tests to pass. We can't use the core mocks for
now since there are circular dependencies there, which breaks our build.
* add signal api unit tests
* privilege unit test api
* Add unit tests on the signals container
* Refactor signals API tests to use core mocks
* Simplifies our mocking verbosity by leveraging core mocks
* Simplifies test setup by isolating a reference to our fetch mock
* Abstracts response structure to pure helper functions
The try/catch tests had some false positives in that nothing would be
asserted if the code did not throw an error. These proved to be masking
a gap in coverage for our get/create signal index requests, which do not
leverage `throwIfNotOk` but instead rely on the fetch to throw an error;
once that behavior is verified we can update those tests to have our
fetchMock throw errors, and we should be all set.
* Simplify signals API tests now that the subjects do less
We no longer re-throw errors, or parse the response, we just return the
result of the client call. Simple!
* Simplify API functions to use implict returns
When possible. Also adds missing error-throwing documentation where
necessary.
* Revert "Display an error toaster on newsfeed fetch failure"
This reverts commit 64213221f5.
* Error property is readonly
* Pull uuid generation into default argument value
* Fix type predicate isApiError
Uses has to properly inspect our errorish object. Turns out we have a
'message' property, not an 'error' property.
* Fix test setup following modification of type predicate
We need a message (via new Error), a body.message, and a
body.status_code to satisfy isApiError.
Co-authored-by: Xavier Mouligneau <189600+XavierM@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Add a hook for seamlessly handling onClick and href props of links, buttons etc
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
* add management section to SavedObjectsType
* adapt import/export routes to get types accessor
* add documentation
* update generated doc
* update migration guide
* use request context to access exportable types
* update generated doc
* adapt SavedObjectsManagement to use the registry
* stop magical tricks about the config type, register it as any other so type.
* fix FTR assertions
* fix so_mixin tests
* register the `config` type from the uiSettings service
* nits and comments
* update generated doc
* remove true from dynamic property definition, use force-cast back for config type
* remove obsolete test comment
in cytoscape graph. Also selects root nodes with no incoming edges
rather than just unconnected nodes.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Prior to this PR, the alerting UI used two HTTP endpoints provided by the
Kibana watcher plugin, to list index and field names. There are now two HTTP
endpoints in the alerting_builtins plugin which will be used instead.
The code for the new endpoints was largely copied from the existing watcher
endpoints, and the HTTP request/response bodies kept pretty much the same.
resolves https://github.com/elastic/kibana/issues/53041
* wip
* wip
* wip
* will this work?
* wip but it works
* pedro
* remove thing
* remove TODOs
* fix type issue
* add tests to check that alert index api works
* Revert "add tests to check that alert index api works"
This reverts commit 5d40ca18337cf8deb63a0291150780ec094db016.
* Moved schema
* undoing my evils
* fix comments. fix incorrect import
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Exclude disallowed, private setting at index creation
* Remove intl from tabs component
* Added logic for checking the current index status
* Added ES contract integration test
Using _cluster/state is considered internal. This adds an integration
test for checking the contract in CI.
* Add the client side notification for closed indices
* First version of end-to-end functionality working
* Clean up unused, incorrect type information
* Fix type issues and added a comment about the new reindex options
* Fixed server side tests, added comments and logic updates
Updated the handling of reindexOptions to make it more
backwards compatible (treat it as if it could be undefined).
Also update the logic for checking for open or closed indices.
No optional chaining! It should break if the response does not
exactly match.
* Clean up unused code
* Improved idempotency of test and check explicitly for "close".
Rather check for the specific value we want, as this is what is
also gauranteed by the tests. In this way, the information we
send back to the client is also more accurate regarding the index
status. If, in future, more index states are introduced this will
need to be revisited if it affects the ability for an index to be
re-indexed.
* Update client-side tests
* Fix types
* Handle a case where the index name provided may be an alias
* Fix types
* merge-conflict: finish merge conflict resolution
* Update x-pack/plugins/upgrade_assistant/public/application/components/tabs/checkup/deprecations/reindex/closed_warning_icon.tsx
Co-Authored-By: Alison Goryachev <alisonmllr20@gmail.com>
* merge-conflict: Remove duplicate import
VSCode does not auto-save as expected :sigh:
* ui: Revisit the UI
Moved the warning icon to inside of the button and tooltip to
on the button.
Added a callout to the reindex flyout for when an index is closed.
* logic: slight update to when the index closed callout is shown
We only show the index closed callout in the flyout when the
reindex operation is not considered "completed"
* tests: fix jest tests
* refactor: remove "openAndClose" from reindex endpoints
"openAndClose" should just happen automatically. The user should
not have to pass the flag in, that would be a weird API. We just
need to warn the user about that reindexing a closed index will
take more resources
* test: update upgrade assistant integration test
* fix: types
* copy: use sentence case
* refactor: use the in scope declaration of reindex op
* test: Clean up tests
Reindexing test was generating index name, could just get it from
server response. Also removed openAndClose from all integration
tests
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
When only one node is displayed, show an empty message.
Also:
* Start adding a basic Jest test for the ServiceMap component
* Fix bug where EuiDocsLink was rendering "children" instead of the actual children
Closes#59326.
Closes#59128.
* use inline snapshots instead of snapshots
* hide input value from error messages
* update core snapshots
* update xpack snapshots
* fix ftr assertions
* fix new snapshots
* hide values for byte_size and duration
* update new snapshots
* remove another byte_size value reference
* fix yet another value references in error messages
* update xpack snapshots
* update xpack ftr assertions
Migrates the client side plugin of transforms to NP.
- Gets rid of the last parts of the shim (http, documentation links)
- Moves the plugin from x-pack/legacy/plugins/transform/public to x-pack/plugins/transform
- Creates a custom mock for appDependencies based on NP services
- Fixes jest tests to get rid of all act() related warnings
Changes the alerting UI to use the new time series query HTTP endpoint provided by the builtin index threshold alertType; previously it used a watcher HTTP endpoint.
This is part of the ongoing index threshold work tracked in https://github.com/elastic/kibana/issues/53041
* Unifying the test index name for resolver and alerts
* Endpoint isn't sending the agent field so check for it
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Added server side logic for handling batch reindex
* Remove literal string interpolation from translation
* Refactor return value of batch endpoint
"sucesses" does not communicate accurately what has happened.
"started" more closely reflects what has happened.
* First iteration of batch queues
* Single queue
Changed the batchqueues implementation to only using a single queue
- since there is only one ES that it is interacting with.
Before continuing with this work, just making sure that these pre-
cautions are necessary!
* Clean up old batch queue implementation
* Slight refactor
* Revert batch queues implementation
* Introduction of QueueSettings
Queue settings can be set on a reindex operation and set a
timemstamp value on the reindex operation for the scheduler
to use down the line for ordering operations and running them
in series
* Updated worker logic to handle items in queue in series
* Refactor /batch endpoint response to "enqueued" not "started"
* Fixed jest tests
* Refactor worker refresh operations for readability
Created a new file op_utils where logic repsonsible for sorting
and ordering reindex operation saved objects is.
* Add batch API integration test
Also assert that reindexing is happening in the expected order
* Added a new endpoint: GET batch/queue
This allows users of the API to see what the current queue state
is for visibility. Using the queue endpoint int he API integration
tests for batch too.
* Reset the queuedAt timestamp on resume
If a reindexOperation is being resumed and put in a queue we
also need to reset the queuedAt timestamp to respect the new
batch queue ordering.
* Fix jest test
Added 'undefined' as the second optional param to
resumeIndexOperation call.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
