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

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.

Commencez par la reproduction Java dans l’issue, en vous concentrant sur TaskOrchestrationContext.waitForExternalEvent et sur l’appel dupliqué à scheduleNewOrchestrationInstance. Exécutez le scénario de déclenchement de l’orchestrateur et vérifiez que le deuxième événement externe expire après une seconde, même lorsqu’une nouvelle tentative de planification de la même ID d’instance est effectuée.