Investigate rollbackEntityOperationsOnExceptions semantics for Durable Entities

[andystaples]

Upstream report: Azure/azure-functions-durable-python#274

Investigate whether azure-functions-durable v2 entities honor the host rollbackEntityOperationsOnExceptions setting. This may require a Durable Functions extension or wire-contract change if the setting is not available in the Python entity request.

Investigation goals

• Verify omitted/default and explicit true: set, delete, create, and in-place mutation followed by an exception are rolled back.
• Verify explicit false: those mutations remain applied.
• Verify that, in a multi-operation batch, only the failed operation is rolled back and successful operations before and after it remain applied.
• Verify callers observe the operation failure without an unintended retry.
• Add end-to-end host coverage for supported v2 providers.
• If the gRPC or extension contract cannot carry this option, identify and link the required extension/protobuf work rather than implementing SDK-only behavior.

[andystaples]

Investigation findings

Verdict: still applicable, with narrower scope.

V2 already implements the safe/default rollback behavior. _execute_entity_batch commits 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:

1. rollbackEntityOperationsOnExceptions=false is not represented end to end. The protobuf request has a generic properties map, but the extension does not populate this setting and the Python worker does not read it.
2. 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 false should 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 tagged fixed-in-v2.

[andystaples]

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.