Immediate and delayed event confirmation

RaiseEvent updates the tentative view and starts submission. Confirmation determines when the event joins the durable, ordered log.

Immediate confirmation

Await ConfirmEvents before returning when the grain method promises a confirmed result:

RaiseEvent(new Deposited(amount));
await ConfirmEvents();

Also await conditional-event tasks. Without reentrant or interleavable calls, this prevents another turn from observing the grain between submission and confirmation.

The tradeoff is availability and latency: the call waits for the selected provider and backing store. A connectivity problem can hold confirmation while the protocol retries.

Delayed confirmation

A grain can return without awaiting ConfirmEvents, or permit interleaving while confirmation is pending. This can improve throughput but changes what the method guarantees.

Use:

• State for the confirmed view.
• TentativeState for confirmed plus locally unconfirmed events.
• UnconfirmedEvents for the pending suffix.

Tentative state isn’t a durable promise. An activation can fail before confirmation, and competing updates can change the final ordering or reject a conditional event.

Orleans scheduling still applies

Reentrancy doesn’t run two grain turns simultaneously on different threads. State can change across an await because another turn can run while the first is suspended. Capture values needed across an await or re-check the state afterward.

Choose and document one semantic per grain method: confirmed-before-return or accepted-for-background-confirmation. Callers shouldn’t have to infer durability from implementation details.