You can find all the API changes here.
The ES|QL helper can now return results as an Apache Arrow Table or RecordBatchReader, which enables high-performance calculations on ES|QL results, even if the response data is larger than the system’s available memory. See [esql-helper] for more information.
The client’s disablePrototypePoisoningProtection option was set to true by default, but when it was set to any other value it was ignored, making it impossible to enable prototype poisoning protection without providing a custom serializer implementation.
Updated TypeScript types based on fixes and improvements to the Elasticsearch specification.
Updated TypeScript types based on fixes and improvements to the Elasticsearch specification.
You can find all the API changes here.
For those that use an observability service that supports OpenTelemetry spans, the client will now automatically generate traces for each Elasticsearch request it makes. See {jsclient}/observability.html#_opentelemetry[the docs] for more information.
Updated types based on fixes and changes to the Elasticsearch specification.
You can find all the API changes here.
A helper method has been added that parses the response of an ES|QL query and converts it into an array of objects. A TypeScript type parameter can also be provided to improve developer experience when working with the result. #2238
The bulk helper now supports an onSuccess callback that will be called for each successful operation. #2199
@elastic/transport v8.6.0 was released, which refactored when and how failed requests are retried. Timed-out requests are no longer retried by default, and retries now use exponential backoff rather than running immediately.
Switching from ^8.4.1 to ~8.4.1 ensures 8.13 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
v8.13.0 was also released depending on v8.4.0 of @elastic/transport instead of v8.4.1, which was unintentional.
You can find all the API changes here.
Ensure new connections inherit client’s set defaults #2159
When instantiating a client, any connection-related defaults (e.g. requestTimeout) set on that client instance would not be inherited by nodes if they were entered as strings rather than a ConnectionOptions object.
Switching from ^8.4.1 to ~8.4.1 ensures 8.12 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
Upgrade transport to 8.4.1 #2137
Upgrades @elastic/transport to 8.4.1 to resolve a bug where arrays in error diagnostics were unintentionally transformed into objects.
Fix hang in bulk helper semaphore #2027
The failing state could be reached when a server’s response times are slower than flushInterval.
You can find all the API changes here.
Switching from ^8.4.0 to ~8.4.0 ensures 8.11 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
You can find all the API changes here.
Enhanced support for redacting potentially sensitive data #2095
@elastic/transport version 8.4.0 introduces enhanced measures for ensuring that request metadata attached to some Error objects is redacted. This functionality is primarily to address custom logging solutions that don’t use common serialization methods like JSON.stringify, console.log, or util.inspect, which were already accounted for.
See [redaction] for more information.
Switching from ^8.3.4 to ~8.3.4 ensures 8.10 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
You can find all the API changes here.
Switching from ^8.3.4 to ~8.3.4 ensures 8.9 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
Upgrade Transport #1968
Upgrades @elastic/transport to the latest patch release to fix a bug that could cause the process to exit when handling malformed HEAD requests.
You can find all the API changes here.
Allow document to be overwritten in onDocument iteratee of bulk helper #1732
In the {jsclient}/client-helpers.html#bulk-helper[bulk helper], documents could not be modified before being sent to Elasticsearch. It is now possible to {jsclient}/client-helpers.html#_modifying_a_document_before_operation[modify a document] before sending it.
Updated user-agent header #1954
The user-agent header the client used to connect to Elasticsearch was using a non-standard format that has been improved.
Switching from ^8.3.2 to ~8.3.2 ensures 8.8 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
You can find all the API changes here.
Fix index drift bug in bulk helper #1759
Fixes a bug in the bulk helper that would cause onDrop to send back the wrong JSON document or error on a nonexistent document when an error occurred on a bulk HTTP request that contained a delete action.
Fix a memory leak caused by an outdated version of Undici #1902
Undici 5.5.1, used by elastic-transport-js, could create a memory leak when a high volume of requests created too many HTTP abort listeners. Upgrading Undici to 5.22.1 removed the memory leak.
You can find all the API changes here.
Fix type declarations for legacy types with a body key #1784
Prior releases contained a bug where type declarations for legacy types that include a body key were not actually importing the type that includes the body key.
Switching from ^8.3.1 to ~8.3.1 ensures 8.7 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
You can find all the API changes here.
Switching from ^8.3.1 to ~8.3.1 ensures 8.6 client users are not required to update to Node.js v18+, which is a new requirement set by @elastic/transport v8.5.0. See elastic/elastic-transport-js#91 for details.
Bump @elastic/transport to 8.3.1+ #1802
The @elastic/transport dependency has been bumped to ~8.3.1 to ensure
fixes to the maxResponseSize option are available in the client.
You can find all the API changes here.
You can find all the API changes here.
You can find all the API changes here.
You can find all the API changes here.
Fix ndjson APIs #1688
The previous release contained a bug that broken ndjson APIs.
We have released v8.2.0-patch.1 to address this.
This fix is the same as the one we have released and we strongly recommend upgrading to this version.
Fix node shutdown apis #1697
The shutdown APIs wheren’t complete, this fix completes them.
Types: move query keys to body #1693
The types definitions where wrongly representing the types of fields present in both query and body.
Drop Node.js v12 #1670
According to our Node.js support matrix.
You can find all the API changes here.
More lenient parameter checks #1662
When creating a new client, an undefined caFingerprint no longer trigger an error for a http connection.
Update TypeScript docs and export estypes #1675
You can import the full TypeScript requests & responses definitions as it follows:
import { estypes } from '@elastic/elasticsearch'If you need the legacy definitions with the body, you can do the following:
import { estypesWithBody } from '@elastic/elasticsearch'Updated hpagent to the latest version transport/#49
You can fing the related changes here.
You can find all the API changes here.
Export SniffingTransport #1653
Now the client exports the SniffingTransport class.
Fix onFlushTimeout timer not being cleared when upstream errors #1616
Fixes a memory leak caused by an error in the upstream dataset of the bulk helper.
Cleanup abort listener transport/#42
The legacy http client was not cleaning up the abort listener, which could cause a memory leak.
Improve undici performances transport/#41
Improve the stream body collection and keep alive timeout.
You can find all the API changes here.
Breaking: Yes | Migration effort: Medium
The current TypeScript definitions will be removed from the client, and the new definitions, which contain request and response definitions as well will be shipped by default.
Breaking: Yes | Migration effort: Large
Maintaining both API styles is not a problem per se, but it makes error handling more convoluted due to async stack traces. Moving to a full-promise API will solve this issue.
// callback-style api
client.search({ params }, { options }, (err, result) => {
console.log(err || result)
})
// promise-style api
client.search({ params }, { options })
.then(console.log)
.catch(console.log)
// async-style (sugar syntax on top of promises)
const response = await client.search({ params }, { options })
console.log(response)If you are already using the promise-style API, this won’t be a breaking change for you.
Breaking: Yes | Migration effort: Small
The old abort API makes sense for callbacks but it’s annoying to use with promises
// callback-style api
const request = client.search({ params }, { options }, (err, result) => {
console.log(err) // RequestAbortedError
})
request.abort()
// promise-style api
const promise = client.search({ params }, { options })
promise
.then(console.log)
.catch(console.log) // RequestAbortedError
promise.abort()Node v12 has added the standard AbortController API which is designed to work well with both callbacks and promises.
const ac = new AbortController()
client.search({ params }, { signal: ac.signal })
.then(console.log)
.catch(console.log) // RequestAbortedError
ac.abort()Breaking: Yes | Migration effort: Small
Thanks to the new types we are developing now we know exactly where a parameter should go. The client API leaks HTTP-related notions in many places, and removing them would definitely improve the DX.
This could be a rather big breaking change, so a double solution could be used during the 8.x lifecycle. (accepting body keys without them being wrapped in the body as well as the current solution).
To convert code from 7.x, you need to remove the body parameter in all the endpoints request.
For instance, this is an example for the search endpoint:
// from
const response = await client.search({
index: 'test',
body: {
query: {
match_all: {}
}
}
})
// to
const response = await client.search({
index: 'test',
query: {
match_all: {}
}
})Breaking: Yes | Migration effort: Small to none
The separated transport has been rewritten in TypeScript and has already dropped the callback style API. Given that now is separated, most of the Elasticsearch specific concepts have been removed, and the client will likely need to extend parts of it for reintroducing them. If you weren’t extending the internals of the client, this won’t be a breaking change for you.
Breaking: Yes | Migration effort: Small
The client API leaks HTTP-related notions in many places, and removing them would definitely improve the DX. The client will expose a new request-specific option to still get the full response details.
The new behaviour returns the body value directly as response.
If you want to have the 7.x response format, you need to add meta : true in the request.
This will return all the HTTP meta information, including the body.
For instance, this is an example for the search endpoint:
// from
const response = await client.search({
index: 'test',
body: {
query: {
match_all: {}
}
}
})
console.log(response) // { body: SearchResponse, statusCode: number, headers: object, warnings: array }
// to
const response = await client.search({
index: 'test',
query: {
match_all: {}
}
})
console.log(response) // SearchResponse
// with a bit of TypeScript and JavaScript magic...
const response = await client.search({
index: 'test',
query: {
match_all: {}
}
}, {
meta: true
})
console.log(response) // { body: SearchResponse, statusCode: number, headers: object, warnings: array }Breaking: Yes | Migration effort: Small to none
Move from the current cluster connection pool to a weight-based implementation. This new implementation offers better performances and runs less code in the background, the old connection pool can still be used. If you weren’t extending the internals of the client, this won’t be a breaking change for you.
Breaking: Yes | Migration effort: Small to none
By default, the HTTP client will no longer be the default Node.js HTTP client, but undici instead. Undici is a brand new HTTP client written from scratch, it offers vastly improved performances and has better support for promises. Furthermore, it offers comprehensive and predictable error handling. The old HTTP client can still be used. If you weren’t extending the internals of the client, this won’t be a breaking change for you.
Breaking: Yes | Migration effort: Medium
Currently, every path or query parameter could be expressed in both snake_case and camelCase. Internally the client will convert everything to snake_case.
This was done in an effort to reduce the friction of migrating from the legacy to the new client, but now it no longer makes sense.
If you are already using snake_case keys, this won’t be a breaking change for you.
Breaking: Yes | Migration effort: Small
People usually refers to this as tls, furthermore, internally we use the tls API and Node.js refers to it as tls everywhere.
// before
const client = new Client({
node: 'https://localhost:9200',
ssl: {
rejectUnauthorized: false
}
})
// after
const client = new Client({
node: 'https://localhost:9200',
tls: {
rejectUnauthorized: false
}
})Breaking: Yes | Migration effort: Small
Prototype poisoning protection is very useful, but it can cause performances issues with big payloads. In v8 it will be removed, and the documentation will show how to add it back with a custom serializer.
Breaking: Yes | Migration effort: Large
Nowadays the client support the entire Elasticsearch API, and the transport.request method can be used if necessary. The client extensions API have no reason to exist.
client.extend('utility.index', ({ makeRequest }) => {
return function _index (params, options) {
// your code
}
})
client.utility.index(...)If you weren’t using client extensions, this won’t be a breaking change for you.
Breaking: No | Migration effort: None
The new separated transport is already written in TypeScript, and it makes sense that the client v8 will be fully written in TypeScript as well.
Breaking: Yes | Migration effort: Small
Currently, the client offers a subset of methods of the EventEmitter class, v8 will ship with a diagnostic property which will be a proper event emitter.
// from
client.on('request', console.log)
// to
client.diagnostic.on('request', console.log)Breaking: Yes | Migration effort: Small
The Cloud configuration does not support ApiKey and Bearer auth, while the auth options does.
There is no need to keep the legacy basic auth support in the cloud configuration.
// before
const client = new Client({
cloud: {
id: '<cloud-id>',
username: 'elastic',
password: 'changeme'
}
})
// after
const client = new Client({
cloud: {
id: '<cloud-id>'
},
auth: {
username: 'elastic',
password: 'changeme'
}
})If you are already passing the basic auth options in the auth configuration, this won’t be a breaking change for you.
Once you call client.close every new request after that will be rejected with a NoLivingConnectionsError. In-flight requests will be executed normally unless an in-flight request requires a retry, in which case it will be rejected.
-
ilm.delete_lifecycle:policyparameter has been renamed toname -
ilm.get_lifecycle:policyparameter has been renamed toname -
ilm.put_lifecycle:policyparameter has been renamed toname -
snapshot.cleanup_repository:repositoryparameter has been renamed toname -
snapshot.create_repository:repositoryparameter has been renamed toname -
snapshot.delete_repository:repositoryparameter has been renamed toname -
snapshot.get_repository:repositoryparameter has been renamed toname -
snapshot.verify_repository:repositoryparameter has been renamed toname
The v7 client provided snake_cased methods, such as client.delete_by_query. This is no longer supported, now only camelCased method are present.
So client.delete_by_query can be accessed with client.deleteByQuery