[Bug]: ctx.map returns MapResult items as LinkedHashMap instead of the declared result type

Đã đóng
  • Có gì không ổn?
#870 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@pcbeingused333 đang làm issue này rồi.

Từ ngày 3/11/2026.

  • #874 của @pcbeingused333 — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
aws, java
Lĩnh vực
backend

Hướng nghiên cứu

Read sdk/src/main/java/software/amazon/lambda/durable/operation/MapOperation.java and trace how itemResultType reaches the serialized MapResult. Start with the existing MapIntegrationTest cases and add coverage for a POJO item on first execution and replay. Done means both paths return items as the declared type; an open pull request is already linked to this issue.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug pkg:sdk
Expected Behavior

DurableContext.map(name, items, Class<O>, fn, config) returns a MapResult<O> whose items are instances of O. This holds on the first execution and on replay.

Actual Behavior

When O is a POJO or record, each item in the returned MapResult is a java.util.LinkedHashMap. Reading an item as O throws ClassCastException.

This happens on the first execution, not only on replay. On completion, MapOperation replaces its result with a serialize-then-deserialize copy, so the first execution returns the same value that replay returns.

Steps to Reproduce
public record Payload(String value) {}

@Test
void itemIsDeclaredType() {
    var runner = LocalDurableTestRunner.create(String.class, (input, context) -> {
        var result = context.map(
                "m",
                List.of("a", "b"),
                Payload.class,
                (item, index, ctx) -> new Payload(item),
                MapConfig.builder().build());
        Object first = result.getResult(0);
        return first.getClass().getName();
    });
    var result = runner.runUntilComplete("x");
    assertEquals(ExecutionStatus.SUCCEEDED, result.getStatus());
    assertEquals(Payload.class.getName(), result.getResult(String.class));
}

The test fails:

expected: <...$Payload> but was: <java.util.LinkedHashMap>
SDK Version

main at 3.0.1-SNAPSHOT. Also reported on 2.x. On 1.2.1 the first execution returns Payload, and replay of a completed map returns LinkedHashMap.

Java Version

17

Is this a regression?

Yes

Last Working Version

None fully. 1.2.1 is correct on the first execution and wrong on replay.

Additional Context

The cause is in MapOperation. The constructor passes new TypeToken<>() {} to its superclass as the result type (sdk/src/main/java/software/amazon/lambda/durable/operation/MapOperation.java, line 83).

  1. That anonymous class is created inside the generic class MapOperation<I, O>.
  2. So the captured type is MapResult<O>, with O still a type variable.
  3. So Jackson has no item type and deserializes each item as a LinkedHashMap.
  4. The constructor receives the caller's TypeToken<O> as itemResultType. It stores it but does not use it to build the result type.

The existing MapIntegrationTest cases use String and Integer items. Jackson deserializes those correctly without type information, so the tests do not catch the bug.

The JavaScript SDK also returns the serdes round-trip of the batch result on both paths. Its items are plain JSON objects, which already match the declared TypeScript type. So keeping the round-trip and fixing the item type keeps Java consistent with JavaScript.

Suggested fix: build a parameterized MapResult<O> type from itemResultType, for example by letting TypeToken be created from a java.lang.reflect.Type. Add integration tests with a POJO item type for the first execution and for replay.

Ngôn ngữ chính
Java
Star
28
Fork
18
Merge trung bình
18 giờ 16 phút
Pull request đã merge (30 ngày)
62

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của aws/aws-durable-execution-sdk-java

Tất cả issue của aws/aws-durable-execution-sdk-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.