microsoft / microsoft/durabletask-java
`TaskOrchestrationContext.waitForExternalEvent` Timeout "Removed" After Attempting to Schedule Duplicate Orchestration
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Java
- Star
- 29
- Fork
- 18
- Merge trung bình
- 1 ngày 10 giờ
- Pull request đã merge (30 ngày)
- 2
Mô tả
Summary
An orchestration which specifies a timeout for waiting on an external event will seemingly have that timeout "removed"/ignored after another attempt is made to schedule an orchestration instance with the same ID.
Steps to Reproduce
- Copy the example below.
- Execute the
orchestrator-triggerfunction via HTTP.
@FunctionName("orchestrator-trigger")
public HttpResponseMessage triggerOrchestrator(
@HttpTrigger(
name = "request",
methods = { HttpMethod.GET },
authLevel = AuthorizationLevel.FUNCTION,
route = "orchestrator/trigger"
)
HttpRequestMessage<String> request,
@DurableClientInput(name = "durableContext")
DurableClientContext durableContext,
ExecutionContext context
) throws InterruptedException {
DurableTaskClient client = durableContext.getClient();
String instanceId = "the-only-instance";
client.scheduleNewOrchestrationInstance("orchestrator", null, instanceId);
client.raiseEvent(instanceId, "first", 1);
// Attempting to schedule another orchestration instance with the same instance ID results
// in the event timeout within the existing orchestrator instance from triggering.
try {
client.scheduleNewOrchestrationInstance("orchestrator", null, instanceId);
} catch (RuntimeException ignored) { }
Thread.sleep(10_000);
client.raiseEvent(instanceId, "second", 2);
return request.createResponseBuilder(HttpStatus.OK).build();
}
@FunctionName("orchestrator")
public void orchestrator(
@DurableOrchestrationTrigger(name = "orchestration")
TaskOrchestrationContext orchestration,
ExecutionContext context
) {
Task<Integer> firstTask =
orchestration.waitForExternalEvent("first", Duration.ofSeconds(1), Integer.class);
Task<Integer> secondTask =
orchestration.waitForExternalEvent("second", Duration.ofSeconds(1), Integer.class);
List<Integer> results = orchestration.allOf(firstTask, secondTask).await();
int first = results.get(0);
int second = results.get(1);
System.out.printf("Triggered! First: %s, Second: %s\n", first, second);
}
Expected Result
The orchestration throws an exception due to the second event not arriving within one second.
Actual Result
After ten seconds, the orchestration prints Triggered! First: 1, Second: 2.
Additional Context
Deleting the entire try/catch block that contains the second scheduleNewOrchestrationInstance call results in the expected outcome - the orchestration throws.
This test case is contrived - my actual use case is:
- A process operates on the combination of a ZIP file and a CSV file.
- These two files are provided to the application separately, in any order, but at roughly the same time.
- Whichever file arrives first needs to start an orchestration instance that will wait for both files.
- We need to avoid a race condition that would result in two separate orchestration instances being created, each waiting for the opposite file. So we'll create a deterministic instance ID based on other data, have the CSV/ZIP receivers always attempt to schedule an orchestration instance with that ID, and ignore the "already exists" error when it occurs.
- The CSV/ZIP receivers then simply send their own single event to the orchestration instance.
- The orchestration instance needs to have a timeout in the situation where the second file never arrives.
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu với bản tái hiện bằng Java trong issue, tập trung vào TaskOrchestrationContext.waitForExternalEvent và lệnh gọi scheduleNewOrchestrationInstance trùng lặp. Chạy kịch bản kích hoạt orchestrator và xác minh rằng sự kiện bên ngoài thứ hai bị timeout sau một giây ngay cả khi việc lập lịch cùng một ID phiên bản được thử lại.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- java
- Lĩnh vực
- backend, distributed-systems
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Đình trệ
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức phù hợp với người mới
- 35/100