Skip to content

Script: Metadata for update context #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 42 commits into
base: ingest_ctx_map_field_prop
Choose a base branch
from

Conversation

stu-elastic
Copy link
Owner

Add metadata for the update context

stu-elastic and others added 30 commits July 5, 2022 18:02
Adds the metadata() API call and a Metadata class for the Update context

There are different metadata available in the update context depending
on whether it is an update or an insert (via upsert).

For update, scripts can read index, id, routing, version and timestamp.

For insert, scripts can read index, id and timestamp.

Scripts can always read and write the op but the available ops are different.
Updates allow 'noop', 'index' and 'delete'.
Inserts allow 'noop' and 'create'.

Refs: elastic#86472
…inancy for UpdateRequestTests.testUpdateScript
Currently when sorting on incompatible types, we get
class_cast_exception error (code 500). This patch improves
the error to explain that the problem is because
of incompatible sort types for the field across
different shards and returns user error (code 400).

Closes elastic#73146
This commit stops adding the geo_shape field mapper by default and adds the mapper only when it is needed.
This change replcase 2 hash map operations with a single one and a null
check.
This class's maps are used very hot in the disk threshold allocation
decider. Moving them from hppc maps to unmodifiable map wrapping
`HashMap` has led to a measurable slowdown in the many-shards benchmark
bootstrapping. Lets use immutable map copies here exclusively to make
performance outright better and more predictable via a single implementation.
We need the metadata in a number of allocation deciders and pass it to other allocation methods.
Passing it here avoids redundant lookups across deciders.
Some polishing of reworked LoggedExec task
This PR adds a new audit trail event for when API keys are updated.
matschaffer and others added 12 commits July 12, 2022 14:24
…iveSizeErrors (elastic#88457)

-1 is handled differently by the xcontent code path so this test will fail when `randomIntBetween` lands on -1.

To fix, we add another integer for the xcontent test which starts at -2.
The API key ID generation is handled by the Request class since elastic#63221.
This makes it possible to audit it when creating or granting API keys.
This PR makes the necessary changes for it to happen.

Relates: elastic#63221
1. Add trace log guards to avoid high cost method
2. Log the time it took to rollup a shard
…astic#88460)

Instead of registering the plugin by default, implementations that need it are responsible on registering the plugin.
It's faster and easier to reason about if we always have
an immutable collections map here and not have the type depend
on what the last operation on the index service was.
* Corrected an incomplete sentence.

* Update docs/reference/aggregations/metrics/avg-aggregation.asciidoc

Co-authored-by: Christos Soulios <1561376+csoulios@users.noreply.github.com>

Co-authored-by: David Kilfoyle <41695641+kilfoyle@users.noreply.github.com>
Co-authored-by: Christos Soulios <1561376+csoulios@users.noreply.github.com>
This PR adds a noop check for API key updates. If we detect a noop
update, i.e., an update that does not result in any changes to the
existing doc, we skip the index step and return updated = false in
the response.

This PR also extends test coverage around various corner cases.
But DEBUG (silent) logging of snapshot restore/completion when
done in the context of CCR or searchable snapshots.
…ermark (elastic#88452)

Fix this test unexpectedly being off by one by increasing the accuracy of the fp division
(better to have a larger dividend and divisor) a little. I could easily reproduce the failure
without the fix but with it, the test cases we use at least run accurate with the change.

closes elastic#88433
…#88476)

Currently, an abort (especially when triggered an index delete) can
manifest as either an aborted snapshot exception, a missing index exception or
an NPE. The latter two show up as noise in logs.
This change catches effectively all of these cleanly as aborted snapshot
exceptions so they don't get logged as warnings and avoids the NPE if
a shard was removed from the index service concurrently by using the
API that throws on missing shards to look it up.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.