Delete By Query deserialization will not account for search failures

已关闭
  • 哪里不对？
#1,349 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@l-trotta 已经在做这个了。

开始于 2026年10月2日。

评估

这个 Issue 还没有评估数据。

描述

Java API client version

8.14.3

Java version

21

Elasticsearch Version

8.19.11

Problem description

Delete by query's response field has a section for failures that is strictly typed as BulkIndexByScrollFailure. However, in the DeleteByQueryResponse that upstream Elasticsearch can return, the failures list is a union of search failures and indexing failures, and the search failures has a different serialization format than the indexing failures (ES9, ES8). Specifically, search failures put the error under reason, and the bulk failures put the error under cause. The result is that if a search failure is serialized by the server, the client fails to deserialize into a DeleteByQueryResponse correctly unless the default deserializer is overridden accordingly.

Reproducing this is challenging in an isolated case because it requires actually reproducing a search failure that serializes this way. The following is contrived, but can sometimes show the issue if given enough attempts - it tries to specifically close the index under deletion in the middle of one of the scroll iterations of a delete by query job.

        ElasticsearchClient client = <create client here>;
        String prefix = "dbq-search-failure-" + UUID.randomUUID();
        String available = prefix + "-available";
        String disappearing = prefix + "-disappearing";
        ExecutorService executor = Executors.newSingleThreadExecutor();
        try {
            for (String index : List.of(available, disappearing)) {
                client.indices().create(request -> request.index(index)
                        .settings(settings -> settings.numberOfShards("1").numberOfReplicas("0")));
            }
            // Sorting keeps the first batches on the available index, avoiding a bulk write failure when the
            // other index closes. Its scroll context still participates, so a later scroll has a search failure.
            for (int position = 0; position < 5; position++) {
                String id = Integer.toString(position);
                Map<String, Integer> document = Map.of("position", position);
                client.index(request -> request.index(available).id(id).document(document));
            }
            client.index(request -> request.index(disappearing).id("last").document(Map.of("position", 100)));
            client.indices().refresh(request -> request.index(available, disappearing));

            Future<DeleteByQueryResponse> deletion = executor.submit(() -> client.deleteByQuery(request -> request
                    .index(available, disappearing)
                    .query(query -> query.matchAll(all -> all))
                    .sort("position:asc")
                    .scrollSize(1L)
                    .scroll(scroll -> scroll.time("1m"))
                    .requestsPerSecond(0.1f)));

            // The first deletion proves the initial search succeeded and both scroll contexts were created.
            long deadline = System.nanoTime() + TimeUnit.SECONDS.toNanos(15);
            while (client.exists(request -> request.index(available).id("0")).value()) {
                if (System.nanoTime() >= deadline) {
                    throw new AssertionError("Delete-by-query did not finish its first batch");
                }
                Thread.sleep(50);
            }
            client.indices().close(request -> request.index(disappearing));

            try {
                // Expected: a result with failures[0].reason.type == search_context_missing_exception.
                // Actual: the generated client models every failure as BulkIndexByScrollFailure.
                return deletion.get(45, TimeUnit.SECONDS);
            } catch (ExecutionException failure) {
                if (failure.getCause() instanceof Exception cause) {
                    throw cause;
                }
                throw failure;
            }
        } finally {
            executor.shutdownNow();
            client.indices().delete(request -> request.index(available, disappearing).ignoreUnavailable(true));
        }
主要语言
Java
星标
525
派生
299
平均合并
1 小时 51 分钟
30 天内合并 PR
17

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

elastic/elasticsearch-java 的其他 Issue

查看 elastic/elasticsearch-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。