Skip to content

5.5.2.1.10. Accept Event Action Node

Mikołaj Milewski edited this page Nov 12, 2026 · 1 revision

Accept Event Action Node

An Accept Event Action Node waits for an incoming event of a declared type. When that event is delivered while the node is active, its action runs and its outgoing flows can continue the Activity. It models an event-accepting action in UML; the event itself is not an object-flow token.

Definition

Register the event type and optional callback with AddAcceptEventAction<TEvent>. The callback can inspect c.Event; the node can also receive ordinary tokens through incoming object flows.

public sealed record PaymentCaptured(string PaymentId, decimal Amount);

The following fragment belongs inside the relevant method or builder callback:

.AddInitial(node => node.AddControlFlow("AcceptPayment"))
.AddAcceptEventAction<PaymentCaptured>(
    "AcceptPayment",
    async c => await payments.RecordCaptureAsync(
        c.Event.PaymentId, c.Event.Amount, c.CancellationToken),
    node => node.AddControlFlow("IssueReceipt"))
.AddAction(
    "IssueReceipt",
    async c => await receipts.IssueAsync(
        c.CancellationToken),
    node => node.AddControlFlow<FinalNode>())
.AddFinal()

The event action is eligible only while its node is active. A later event is not consumed once the modeled execution has ended or the node is no longer active. Multiple event types can be handled by separate event-accepting nodes; the OneOf extension can combine alternatives where appropriate. See Send Event Action Node, Time Event Action Node, and Activities.

Steering a live stream

An active accept-event node can handle a regular steering event while unrelated streamed actions are still running on Orleans. The event remains ordered behind earlier regular transactions; its source is transactional even if streamed control tokens enabled the accepting node. A downstream consumer that mixes its output with streamed input becomes streamed, allowing the regular call to hand off that work and return.

Updating context.Behavior.Values makes configuration immediately visible to later reads in the live network, without rollback if the regular event fails during streaming. The accepting node must still be active; streaming does not make an arbitrary event acceptable. See Activity Streaming.

Accept a structural event by name

When the event is defined in Stateflows' structural event registry rather than as a CLR event class, use the overload that takes its registered event name. Its callback receives a StructuralEvent, whose values are read by field name:

using Stateflows.Common;
using Stateflows.Events;

// Register this definition during Stateflows configuration:
builder.AddEvents(events => events
    .AddEvent("payment-captured", e => e
        .AddField("paymentId", FieldType.String)
        .AddField("amount", FieldType.Decimal)));

// In the Activity definition:
.AddAcceptEventAction(
    "payment-captured",
    "AcceptPayment",
    async c => await payments.RecordCaptureAsync(
        c.Event.Get<string>("paymentId"),
        c.Event.Get<decimal>("amount"),
        c.CancellationToken),
    node => node.AddControlFlow("IssueReceipt"))

This is different from AddAcceptEventAction<TEvent>: the string overload matches the registered structural event name, and the callback receives StructuralEvent, not a CLR class. Structural definitions and IEventFactory creation are described in Events.

Clone this wiki locally