Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

`rebuild()` of bulk operations (`IndexOperation`, `CreateOperation`, `UpdateOperation`) drops most fields

Abierto
  • ¿Algo no está bien?
#1,353 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
50/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
elasticsearch, java
Área
api

Línea de trabajo

The bug is in the private Builder(IndexOperation), Builder(CreateOperation) and Builder(UpdateOperation) constructors, which copy too few fields. Those classes inherit from BulkOperationBase and WriteOperation, and the reproducer in the issue shows which properties go missing. The likely cause is the code generator, so check whether the fix belongs in the generated sources or in the generator. Done means op.rebuild().build() equals op for all three operation types, with the builder typed as Builder<TDocument>.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Area: Generator Category: Bug
Java API client version

9.5.4 (also current main)

Java version

25

Elasticsearch Version

9.5.4

Problem description

(full disclosure: analysis by copilot)

rebuild() should return a builder "initialized with field values of this instance". For the bulk operation classes it doesn't: most fields are lost.

Expected: op.rebuild().build() is equal to op.

Actual:

  • IndexOperation and CreateOperation: the private Builder(IndexOperation<TDocument> instance) / Builder(CreateOperation<TDocument> instance) constructors are empty. Nothing is copied:

    • fields inherited from BulkOperationBase: id, index, routing, ifSeqNo, ifPrimaryTerm, version, versionType;
    • fields inherited from WriteOperation: pipeline, requireAlias, dynamicTemplates;
    • their own fields: document and tDocumentSerializer.

    Because document is required, rebuild().build() throws a MissingRequiredPropertyException. If you set a new document first (for example .document(binaryData)), it builds without errors, but without _id, _index, routing and so on.

  • UpdateOperation: only requireAlias and retryOnConflict are copied. The inherited BulkOperationBase fields, action, binaryAction and the serializers are lost.

This looks like a code generator problem. Fields inherited from a generated base class are never copied, and neither are fields of the generic type parameter. Request classes without a base class, such as IndexRequest, copy their fields correctly.

Reproducer:

IndexOperation<Map<String, Object>> op = IndexOperation.of(b -> b
    .index("my-index")
    .id("1")
    .routing("r1")
    .ifSeqNo(5L)
    .ifPrimaryTerm(1L)
    .pipeline("my-pipeline")
    .document(Map.of("field", "value")));

// throws MissingRequiredPropertyException: Missing required property 'IndexOperation.document'
op.rebuild().build();

// builds without errors, but all values are lost
IndexOperation<?> copy = op.rebuild().document(Map.of("field", "value")).build();
System.out.println(copy.index());   // null, expected "my-index"
System.out.println(copy.id());      // null, expected "1"
System.out.println(copy.routing()); // null, expected "r1"
System.out.println(copy.pipeline()); // null, expected "my-pipeline"

CreateOperation behaves the same. For UpdateOperation, rebuild().build() does not throw, but only requireAlias and retryOnConflict are kept:

UpdateOperation<Object, Object> op = UpdateOperation.of(b -> b
    .index("my-index")
    .id("1")
    .routing("r1")
    .retryOnConflict(3)
    .action(a -> a.docAsUpsert(true)));

UpdateOperation<?, ?> copy = op.rebuild().build();
System.out.println(copy.index());           // null, expected "my-index"
System.out.println(copy.id());              // null, expected "1"
System.out.println(copy.routing());         // null, expected "r1"
System.out.println(copy.retryOnConflict()); // 3
System.out.println(copy.action());          // null

Context: I hit this in Spring Data Elasticsearch. Like the client's own BulkIngester, it needs to replace the document of an operation with a pre-serialized BinaryData so that it can measure its size. The obvious way is op.rebuild().document(binaryData).build(), but that silently drops _id and _index. So we copy all properties by hand, as IngesterOperation.copyIndexProperties() / copyBaseProperties() do.
see https://github.com/spring-projects/spring-data-elasticsearch/pull/3357

Note: rebuild() also returns the raw type Builder instead of Builder<TDocument>, so callers get unchecked warnings.

Lenguaje dominante
Java
Estrellas
525
Forks
299
Merge medio
6 h 12 min
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de elastic/elasticsearch-java

Todos los issues de elastic/elasticsearch-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.