Skip to content

.pr_agent_accepted_suggestions

Jump to bottom Edit New page
qodo-merge-bot edited this page Apr 13, 2026 · 3 revisions
                     PR 921 (2026-04-13)                    
[reliability] Node engine mismatch
Node engine mismatch package.json declares Node ">=22.0.0" but the newly added dev tools (oxlint/oxfmt) require Node "^20.19.0 || >=22.12.0", leaving Node 22.0.0–22.11.x as 'supported' by the repo but unsupported by required lint/format tooling.

Issue description

package.json advertises engines.node: ">=22.0.0", but newly introduced tooling (oxlint, oxfmt) declares engines.node: "^20.19.0 || >=22.12.0". This leaves a gap where Node 22.0.0–22.11.x is allowed by the repo but not by the tools used in pnpm run lint / pnpm run format.

Issue Context

  • oxlint/oxfmt are now part of the default dev workflow (lint, lint:fix, format, format:check).
  • Their engines constraints should be reflected in the repo’s declared Node support.

Fix Focus Areas

  • package.json[98-100]

Suggested fix

Update package.json to align the engines.node range with the tools, for example:

  • "node": "^20.19.0 || >=22.12.0" Optionally, also ensure CI uses a Node version that satisfies this range (if CI is intended to run lint/format or dev tooling).
                     PR 914 (2026-04-12)                    
[correctness] Missing elasticsearch8 dependency
Missing elasticsearch8 dependency `package.json` removes the `elasticsearch8` alias but `databases/elasticsearch_db.ts` still imports from `elasticsearch8`, so builds/runtime will fail with a module resolution error.

Issue description

databases/elasticsearch_db.ts still imports from elasticsearch8 even though the PR removed that alias from package.json. This will break TypeScript compilation and runtime module resolution.

Issue Context

The dependency was renamed from the alias elasticsearch8 to the real package name @elastic/elasticsearch.

Fix Focus Areas

  • databases/elasticsearch_db.ts[17-25]
  • package.json[25-45]

What to change

  • Replace import {Client} from 'elasticsearch8' with import {Client} from '@elastic/elasticsearch'.
  • Update the MappingTypeMapping type import to the correct path/type for @elastic/elasticsearch@9 (or replace it with an equivalent local type if the exported type name/path changed).
  • Run pnpm run build / pnpm run ts-check to confirm module resolution and types are correct.
[correctness] ES9 breaks type-based migration
ES9 breaks type-based migration The Elasticsearch test suite and migration code rely on ES7 mapping types (`type` request parameter and `_type` in hits), but the PR upgrades the test container to Elasticsearch 9.3.3 where mapping types are removed, so the ES migration tests (and schema v1→v2 migration logic) will fail.

Issue description

Elasticsearch 9.x does not support mapping types, but the test suite and migration code depend on types (client.index({type: ...}) and reading _type from search hits). Switching the container image to elasticsearch:9.3.3 will cause these tests and migration behaviors to break.

Issue Context

The tests explicitly state they must stay on ES 7.17.x to verify the legacy schema migration.

Fix Focus Areas

  • test/elasticsearch/test.elasticsearch.spec.ts[20-42]
  • test/elasticsearch/test.elasticsearch.spec.ts[100-115]
  • databases/elasticsearch_db.ts[60-73]

What to change

Choose one:

  1. Keep tests/migration coverage: revert the test container (and any other test infra) back to an ES 7.17.x image.
  2. Drop ES7 migration path: refactor migration logic + tests to no longer rely on mapping types (including removing _type usage and rewriting how legacy keys are derived), then keep ES9. Make sure pnpm run test elasticsearch passes after the change.
[reliability] Node engine mismatch
Node engine mismatch The new Elasticsearch client stack requires Node >=20.18.1 via transitive dependencies, but the package still declares `engines.node >=16.20.1`, so installs and/or runtime will fail for currently-supported Node versions.

Issue description

@elastic/elasticsearch@9 brings in dependencies that require Node 20+ (and undici specifically requires >=20.18.1), but the package still advertises engines.node: >=16.20.1.

Issue Context

This project is published to npm; incorrect engines leads users to install on unsupported Node versions and then hit failures.

Fix Focus Areas

  • package.json[97-100]
  • package.json[25-45]
  • pnpm-lock.yaml[241-248]
  • pnpm-lock.yaml[3118-3121]

What to change

  • Either bump engines.node to at least >=20.18.1 (and consider updating CI to explicitly test that),
  • Or pin/downgrade the Elasticsearch client/transport/undici stack to versions that support the currently-declared Node engine range.
[correctness] Missing elasticsearch8 dependency
Missing elasticsearch8 dependency `package.json` removes the `elasticsearch8` alias but `databases/elasticsearch_db.ts` still imports from `elasticsearch8`, so builds/runtime will fail with a module resolution error.

Issue description

databases/elasticsearch_db.ts still imports from elasticsearch8 even though the PR removed that alias from package.json. This will break TypeScript compilation and runtime module resolution.

Issue Context

The dependency was renamed from the alias elasticsearch8 to the real package name @elastic/elasticsearch.

Fix Focus Areas

  • databases/elasticsearch_db.ts[17-25]
  • package.json[25-45]

What to change

  • Replace import {Client} from 'elasticsearch8' with import {Client} from '@elastic/elasticsearch'.
  • Update the MappingTypeMapping type import to the correct path/type for @elastic/elasticsearch@9 (or replace it with an equivalent local type if the exported type name/path changed).
  • Run pnpm run build / pnpm run ts-check to confirm module resolution and types are correct.
[correctness] ES9 breaks type-based migration
ES9 breaks type-based migration The Elasticsearch test suite and migration code rely on ES7 mapping types (`type` request parameter and `_type` in hits), but the PR upgrades the test container to Elasticsearch 9.3.3 where mapping types are removed, so the ES migration tests (and schema v1→v2 migration logic) will fail.

Issue description

Elasticsearch 9.x does not support mapping types, but the test suite and migration code depend on types (client.index({type: ...}) and reading _type from search hits). Switching the container image to elasticsearch:9.3.3 will cause these tests and migration behaviors to break.

Issue Context

The tests explicitly state they must stay on ES 7.17.x to verify the legacy schema migration.

Fix Focus Areas

  • test/elasticsearch/test.elasticsearch.spec.ts[20-42]
  • test/elasticsearch/test.elasticsearch.spec.ts[100-115]
  • databases/elasticsearch_db.ts[60-73]

What to change

Choose one:

  1. Keep tests/migration coverage: revert the test container (and any other test infra) back to an ES 7.17.x image.
  2. Drop ES7 migration path: refactor migration logic + tests to no longer rely on mapping types (including removing _type usage and rewriting how legacy keys are derived), then keep ES9. Make sure pnpm run test elasticsearch passes after the change.
[reliability] Node engine mismatch
Node engine mismatch The new Elasticsearch client stack requires Node >=20.18.1 via transitive dependencies, but the package still declares `engines.node >=16.20.1`, so installs and/or runtime will fail for currently-supported Node versions.

Issue description

@elastic/elasticsearch@9 brings in dependencies that require Node 20+ (and undici specifically requires >=20.18.1), but the package still advertises engines.node: >=16.20.1.

Issue Context

This project is published to npm; incorrect engines leads users to install on unsupported Node versions and then hit failures.

Fix Focus Areas

  • package.json[97-100]
  • package.json[25-45]
  • pnpm-lock.yaml[241-248]
  • pnpm-lock.yaml[3118-3121]

What to change

  • Either bump engines.node to at least >=20.18.1 (and consider updating CI to explicitly test that),
  • Or pin/downgrade the Elasticsearch client/transport/undici stack to versions that support the currently-declared Node engine range.
[correctness] Missing elasticsearch8 dependency
Missing elasticsearch8 dependency `package.json` removes the `elasticsearch8` alias but `databases/elasticsearch_db.ts` still imports from `elasticsearch8`, so builds/runtime will fail with a module resolution error.

Issue description

databases/elasticsearch_db.ts still imports from elasticsearch8 even though the PR removed that alias from package.json. This will break TypeScript compilation and runtime module resolution.

Issue Context

The dependency was renamed from the alias elasticsearch8 to the real package name @elastic/elasticsearch.

Fix Focus Areas

  • databases/elasticsearch_db.ts[17-25]
  • package.json[25-45]

What to change

  • Replace import {Client} from 'elasticsearch8' with import {Client} from '@elastic/elasticsearch'.
  • Update the MappingTypeMapping type import to the correct path/type for @elastic/elasticsearch@9 (or replace it with an equivalent local type if the exported type name/path changed).
  • Run pnpm run build / pnpm run ts-check to confirm module resolution and types are correct.
[correctness] ES9 breaks type-based migration
ES9 breaks type-based migration The Elasticsearch test suite and migration code rely on ES7 mapping types (`type` request parameter and `_type` in hits), but the PR upgrades the test container to Elasticsearch 9.3.3 where mapping types are removed, so the ES migration tests (and schema v1→v2 migration logic) will fail.

Issue description

Elasticsearch 9.x does not support mapping types, but the test suite and migration code depend on types (client.index({type: ...}) and reading _type from search hits). Switching the container image to elasticsearch:9.3.3 will cause these tests and migration behaviors to break.

Issue Context

The tests explicitly state they must stay on ES 7.17.x to verify the legacy schema migration.

Fix Focus Areas

  • test/elasticsearch/test.elasticsearch.spec.ts[20-42]
  • test/elasticsearch/test.elasticsearch.spec.ts[100-115]
  • databases/elasticsearch_db.ts[60-73]

What to change

Choose one:

  1. Keep tests/migration coverage: revert the test container (and any other test infra) back to an ES 7.17.x image.
  2. Drop ES7 migration path: refactor migration logic + tests to no longer rely on mapping types (including removing _type usage and rewriting how legacy keys are derived), then keep ES9. Make sure pnpm run test elasticsearch passes after the change.
[reliability] Node engine mismatch
Node engine mismatch The new Elasticsearch client stack requires Node >=20.18.1 via transitive dependencies, but the package still declares `engines.node >=16.20.1`, so installs and/or runtime will fail for currently-supported Node versions.

Issue description

@elastic/elasticsearch@9 brings in dependencies that require Node 20+ (and undici specifically requires >=20.18.1), but the package still advertises engines.node: >=16.20.1.

Issue Context

This project is published to npm; incorrect engines leads users to install on unsupported Node versions and then hit failures.

Fix Focus Areas

  • package.json[97-100]
  • package.json[25-45]
  • pnpm-lock.yaml[241-248]
  • pnpm-lock.yaml[3118-3121]

What to change

  • Either bump engines.node to at least >=20.18.1 (and consider updating CI to explicitly test that),
  • Or pin/downgrade the Elasticsearch client/transport/undici stack to versions that support the currently-declared Node engine range.
[correctness] Missing elasticsearch8 dependency
Missing elasticsearch8 dependency `package.json` removes the `elasticsearch8` alias but `databases/elasticsearch_db.ts` still imports from `elasticsearch8`, so builds/runtime will fail with a module resolution error.

Issue description

databases/elasticsearch_db.ts still imports from elasticsearch8 even though the PR removed that alias from package.json. This will break TypeScript compilation and runtime module resolution.

Issue Context

The dependency was renamed from the alias elasticsearch8 to the real package name @elastic/elasticsearch.

Fix Focus Areas

  • databases/elasticsearch_db.ts[17-25]
  • package.json[25-45]

What to change

  • Replace import {Client} from 'elasticsearch8' with import {Client} from '@elastic/elasticsearch'.
  • Update the MappingTypeMapping type import to the correct path/type for @elastic/elasticsearch@9 (or replace it with an equivalent local type if the exported type name/path changed).
  • Run pnpm run build / pnpm run ts-check to confirm module resolution and types are correct.
[correctness] ES9 breaks type-based migration
ES9 breaks type-based migration The Elasticsearch test suite and migration code rely on ES7 mapping types (`type` request parameter and `_type` in hits), but the PR upgrades the test container to Elasticsearch 9.3.3 where mapping types are removed, so the ES migration tests (and schema v1→v2 migration logic) will fail.

Issue description

Elasticsearch 9.x does not support mapping types, but the test suite and migration code depend on types (client.index({type: ...}) and reading _type from search hits). Switching the container image to elasticsearch:9.3.3 will cause these tests and migration behaviors to break.

Issue Context

The tests explicitly state they must stay on ES 7.17.x to verify the legacy schema migration.

Fix Focus Areas

  • test/elasticsearch/test.elasticsearch.spec.ts[20-42]
  • test/elasticsearch/test.elasticsearch.spec.ts[100-115]
  • databases/elasticsearch_db.ts[60-73]

What to change

Choose one:

  1. Keep tests/migration coverage: revert the test container (and any other test infra) back to an ES 7.17.x image.
  2. Drop ES7 migration path: refactor migration logic + tests to no longer rely on mapping types (including removing _type usage and rewriting how legacy keys are derived), then keep ES9. Make sure pnpm run test elasticsearch passes after the change.
[reliability] Node engine mismatch
Node engine mismatch The new Elasticsearch client stack requires Node >=20.18.1 via transitive dependencies, but the package still declares `engines.node >=16.20.1`, so installs and/or runtime will fail for currently-supported Node versions.

Issue description

@elastic/elasticsearch@9 brings in dependencies that require Node 20+ (and undici specifically requires >=20.18.1), but the package still advertises engines.node: >=16.20.1.

Issue Context

This project is published to npm; incorrect engines leads users to install on unsupported Node versions and then hit failures.

Fix Focus Areas

  • package.json[97-100]
  • package.json[25-45]
  • pnpm-lock.yaml[241-248]
  • pnpm-lock.yaml[3118-3121]

What to change

  • Either bump engines.node to at least >=20.18.1 (and consider updating CI to explicitly test that),
  • Or pin/downgrade the Elasticsearch client/transport/undici stack to versions that support the currently-declared Node engine range.
[correctness] Missing elasticsearch8 dependency
Missing elasticsearch8 dependency `package.json` removes the `elasticsearch8` alias but `databases/elasticsearch_db.ts` still imports from `elasticsearch8`, so builds/runtime will fail with a module resolution error.

Issue description

databases/elasticsearch_db.ts still imports from elasticsearch8 even though the PR removed that alias from package.json. This will break TypeScript compilation and runtime module resolution.

Issue Context

The dependency was renamed from the alias elasticsearch8 to the real package name @elastic/elasticsearch.

Fix Focus Areas

  • databases/elasticsearch_db.ts[17-25]
  • package.json[25-45]

What to change

  • Replace import {Client} from 'elasticsearch8' with import {Client} from '@elastic/elasticsearch'.
  • Update the MappingTypeMapping type import to the correct path/type for @elastic/elasticsearch@9 (or replace it with an equivalent local type if the exported type name/path changed).
  • Run pnpm run build / pnpm run ts-check to confirm module resolution and types are correct.
[correctness] ES9 breaks type-based migration
ES9 breaks type-based migration The Elasticsearch test suite and migration code rely on ES7 mapping types (`type` request parameter and `_type` in hits), but the PR upgrades the test container to Elasticsearch 9.3.3 where mapping types are removed, so the ES migration tests (and schema v1→v2 migration logic) will fail.

Issue description

Elasticsearch 9.x does not support mapping types, but the test suite and migration code depend on types (client.index({type: ...}) and reading _type from search hits). Switching the container image to elasticsearch:9.3.3 will cause these tests and migration behaviors to break.

Issue Context

The tests explicitly state they must stay on ES 7.17.x to verify the legacy schema migration.

Fix Focus Areas

  • test/elasticsearch/test.elasticsearch.spec.ts[20-42]
  • test/elasticsearch/test.elasticsearch.spec.ts[100-115]
  • databases/elasticsearch_db.ts[60-73]

What to change

Choose one:

  1. Keep tests/migration coverage: revert the test container (and any other test infra) back to an ES 7.17.x image.
  2. Drop ES7 migration path: refactor migration logic + tests to no longer rely on mapping types (including removing _type usage and rewriting how legacy keys are derived), then keep ES9. Make sure pnpm run test elasticsearch passes after the change.
[reliability] Node engine mismatch
Node engine mismatch The new Elasticsearch client stack requires Node >=20.18.1 via transitive dependencies, but the package still declares `engines.node >=16.20.1`, so installs and/or runtime will fail for currently-supported Node versions.

Issue description

@elastic/elasticsearch@9 brings in dependencies that require Node 20+ (and undici specifically requires >=20.18.1), but the package still advertises engines.node: >=16.20.1.

Issue Context

This project is published to npm; incorrect engines leads users to install on unsupported Node versions and then hit failures.

Fix Focus Areas

  • package.json[97-100]
  • package.json[25-45]
  • pnpm-lock.yaml[241-248]
  • pnpm-lock.yaml[3118-3121]

What to change

  • Either bump engines.node to at least >=20.18.1 (and consider updating CI to explicitly test that),
  • Or pin/downgrade the Elasticsearch client/transport/undici stack to versions that support the currently-declared Node engine range.
Add a custom footer
Add a custom sidebar

Clone this wiki locally
⚡