I discovered there were a few problems that prevented "carryover" events from working correctly. There were a few issues that needed to be addressed:
The unprocessed external events needed to be sent back to the sidecar as "carryover" events. Sending events wasn't sufficient as I originally thought.
The sidecar didn't support carryover events (it would fail with a TODO error message)
I have fixed both of these issues. The sidecar library has been updated on myget.org (see change here) and I've also updated the cgillum/durabletask-sidecar:latest docker container image with these changes.
For this PR, I changed the behavior of the continueAsNew API to simply set some flags instead of creating the orchestration completed action. The orchestration completed action will be created only after all the history events have been played. This allows us to add all the unprocessed external event messages to the completed action's "carryover events" collection.
As a bonus, I added some checks to throw an exception if someone tries to take any action after an orchestrator has completed. Users shouldn't be doing this, and the behavior would otherwise be undefined.
This PR is an update to @kaibocai's continue-as-new PR: https://github.com/microsoft/durabletask-java/pull/22
I discovered there were a few problems that prevented "carryover" events from working correctly. There were a few issues that needed to be addressed:
I have fixed both of these issues. The sidecar library has been updated on myget.org (see change here) and I've also updated the
cgillum/durabletask-sidecar:latestdocker container image with these changes.For this PR, I changed the behavior of the
continueAsNewAPI to simply set some flags instead of creating the orchestration completed action. The orchestration completed action will be created only after all the history events have been played. This allows us to add all the unprocessed external event messages to the completed action's "carryover events" collection.As a bonus, I added some checks to throw an exception if someone tries to take any action after an orchestrator has completed. Users shouldn't be doing this, and the behavior would otherwise be undefined.
I also made some minor changes to the test logic.