`TaskOrchestrationContext.waitForExternalEvent` Timeout "Removed" After Attempting to Schedule Duplicate Orchestration

[ScottHamper]

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

1. Copy the example below.
2. Execute the orchestrator-trigger function 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.

[ScottHamper]

Some more details after further investigation:

• Adding a client.waitForInstanceStart(instanceId, Duration.ofMinutes(1)) call before sending the first event results in the expected outcome. It feels like a user error on my part to attempt to raise events before guaranteeing the orchestration instance has started. However, it does seem strange to me that both events do end up making it to the orchestration instance despite not waiting for it to start. And it still feels like the orchestration instance should timeout while waiting for the second event.
• I am using the MSSQL storage provider for Durable Task.