Repository navigation
Investigate rollbackEntityOperationsOnExceptions semantics for Durable Entities #241
Description
Activity
Investigation findings
Verdict: still applicable, with narrower scope.
V2 already implements the safe/default rollback behavior.
_execute_entity_batchcommits after each successful operation and unconditionally rolls back after an exception (worker path).StateShim.rollback()restores both serialized state and accumulated operation actions (state shim), so a failed operation does not retain its state mutation, signal, or orchestration-start action. Per-operation checkpoints also preserve prior successful operations in the same batch.Two gaps remain:
rollbackEntityOperationsOnExceptions=falseis not represented end to end. The protobuf request has a genericpropertiesmap, but the extension does not populate this setting and the Python worker does not read it.- Existing failure tests throw without first mutating state, so they do not verify set/delete/action rollback or multi-operation checkpoint behavior through the batch executor and a host-backed provider.
Keeping this issue open to add regression coverage and decide whether
falseshould be implemented across the extension/SDK boundary or explicitly documented as unsupported for v2 out-of-process workers. The upstream issue should not yet be taggedfixed-in-v2.This will be resolvable once Azure/azure-functions-durable-extension#3510 lands in the extension bundles. However, this does not mean that we should simply naively implement the rollback change based on the flag alone. Summarizing the conversation from that pr: There is some risk that it would be a breaking change for other SDKs to add the feature, it doesn't save on serialization cost, and there's a question of whether any user would even want this behavior, as, on first glance, it seems only counter-intuitive and harmful.
I personally think there is merit to implementing it - enabling entities to persist state through failures means that well-designed user entities that track their own executions/failures through the entity state become possible, for example - but we should only proceed here after a protracted discussion and thoughtful decision, and after double-checking that the default behavior is sane.
Upstream report: Azure/azure-functions-durable-python#274
Investigate whether
azure-functions-durablev2 entities honor the hostrollbackEntityOperationsOnExceptionssetting. This may require a Durable Functions extension or wire-contract change if the setting is not available in the Python entity request.Investigation goals
true: set, delete, create, and in-place mutation followed by an exception are rolled back.false: those mutations remain applied.