Skip to content

Returning Side Effects from Reactor Handler Methods

Reactor handler methods can return side-effect events directly instead of taking a dependency on IEventLog. The framework automatically appends the returned events to the correct sequence after the handler completes.

Important: Side-effect appends are not fire-and-forget. If a returned event fails to append — a constraint violation, a concurrency conflict, or an error — the reactor’s partition fails with the failure details and is retried per the observer’s retry policy. Failures never pass silently. See Error handling.

Return a single event directly from a handler method — synchronously or as a Task<T>:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.Reactors;
[EventType]
public record SideEffectsBookReserved(string Isbn);
[EventType]
public record StockDecreased(string Isbn, int Quantity);
public class WarehouseReactor : IReactor
{
public StockDecreased BookReserved(SideEffectsBookReserved @event, EventContext context) =>
new(@event.Isbn, 1);
public async Task<StockDecreased> BookReservedAsync(SideEffectsBookReserved @event, EventContext context)
{
var available = await FetchCurrentStockAsync(@event.Isbn);
return new StockDecreased(@event.Isbn, available);
}
Task<int> FetchCurrentStockAsync(string isbn) => Task.FromResult(0);
}

The returned event is appended to the event log using the EventSourceId from the incoming EventContext. No IEventLog injection required.

Return IEnumerable<TEvent> to append several events in one handler call:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.Reactors;
[EventType]
public record MultipleSideEffectsBookReserved(string Isbn);
[EventType]
public record MultipleStockDecreased(string Isbn, int Quantity);
[EventType]
public record StockLow(string Isbn);
public class InventoryReactor : IReactor
{
public IEnumerable<object> BookReserved(MultipleSideEffectsBookReserved @event, EventContext context) =>
[
new MultipleStockDecreased(@event.Isbn, 1),
new StockLow(@event.Isbn),
];
}

Everything above lands the returned event on the triggering event’s EventSourceId — optionally redirected once for the whole reactor via ICanProvideEventSourceId. That covers most reactors. But automation and translation reactors often need to write to a different entity than the one that triggered them — or to several at once.

Picture a library. A member reserves a book, and that reservation is a fact about the book:

using Cratis.Chronicle.Events;
public readonly record struct MemberId(string Value)
{
public static implicit operator EventSourceId(MemberId id) => new(id.Value);
}
public readonly record struct Isbn(string Value)
{
public static implicit operator EventSourceId(Isbn id) => new(id.Value);
}
[EventType]
public record BookReserved(MemberId MemberId, Isbn Isbn);

When it happens you want to record activity on the member — a different event source altogether. Return an EventForEventSourceId and pick the target EventSourceId yourself:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.EventSequences;
using Cratis.Chronicle.Reactors;
[EventType]
public record MemberActivityRecorded(Isbn Isbn);
public class ReservationReactor : IReactor
{
public EventForEventSourceId BookReserved(BookReserved @event, EventContext context) =>
new(@event.MemberId, new MemberActivityRecorded(@event.Isbn));
}

MemberActivityRecorded is appended to @event.MemberId, not to the book that triggered the reactor — so it shows up on the member’s stream, ready for a member-activity projection to pick up.

A single reservation usually ripples to more than one entity: the member gains activity, and the book loses stock. Return IEnumerable<EventForEventSourceId> to fan out to several event source ids in one go — they are appended together as a single transaction:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.EventSequences;
using Cratis.Chronicle.Reactors;
[EventType]
public record FanOutStockDecreased(Isbn Isbn, int Quantity);
public class ReservationFanOutReactor : IReactor
{
public IEnumerable<EventForEventSourceId> BookReserved(BookReserved @event, EventContext context) =>
[
new(@event.MemberId, new MemberActivityRecorded(@event.Isbn)),
new(@event.Isbn, new FanOutStockDecreased(@event.Isbn, 1)),
];
}

Each EventForEventSourceId is self-describing: alongside the source id it carries the event stream type and id, source type, subject, occurred time, tags and causation. Set only the ones you need — the rest fall back to sensible defaults:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.EventSequences;
using Cratis.Chronicle.Reactors;
public class ExplicitMetadataReactor : IReactor
{
public EventForEventSourceId BookReserved(BookReserved @event, EventContext context) =>
new(@event.MemberId, new MemberActivityRecorded(@event.Isbn))
{
EventStreamType = new EventStreamType("members"),
Subject = new Subject(@event.MemberId.Value),
};
}

Two modes: a bare event uses the reactor’s resolved metadata — its [EventStreamType]/[EventSourceType] attributes and ICanProvide* interfaces. An EventForEventSourceId is the explicit mode: it is self-describing and uses only the values on it, so the reactor’s metadata does not apply (an unset field takes the append default such as EventStreamType.All, and an omitted Subject is resolved from the event). Reach for a bare event when you want “use my reactor’s config”, and an EventForEventSourceId when you want “I’ll specify exactly where and how”.

You can also mix the two in a single IEnumerable<object> return — each bare event uses the reactor’s resolved metadata and the triggering event source id, while each EventForEventSourceId keeps its own. They are appended together as one transaction:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.EventSequences;
using Cratis.Chronicle.Reactors;
[EventType]
public record ActivityLogged(Isbn Isbn);
public class MixedSideEffectsReactor : IReactor
{
public IEnumerable<object> BookReserved(BookReserved @event, EventContext context) =>
[
new ActivityLogged(@event.Isbn),
new EventForEventSourceId(@event.MemberId, new MemberActivityRecorded(@event.Isbn)),
];
}

Returning events is convenient, but sometimes the decision is only valid against the exact event-log state the reactor read. Return EventsWithConcurrencyScopes to submit an ordered list of EventForEventSourceId values and its concurrency scopes through one AppendMany call:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.EventSequences;
using Cratis.Chronicle.EventSequences.Concurrency;
using Cratis.Chronicle.Reactors;
[EventType]
public record ReservationConfirmed(Isbn Isbn);
public class ReservationConfirmationReactor : IReactor
{
public EventsWithConcurrencyScopes BookReserved(BookReserved @event, EventContext context) =>
new(
[new EventForEventSourceId(context.EventSourceId, new ReservationConfirmed(@event.Isbn))],
new Dictionary<EventSourceId, ConcurrencyScope>
{
[context.EventSourceId] = new(
context.SequenceNumber,
EventSourceId: context.EventSourceId),
});
}

Here the reactor appends only if no later event for the triggering source has appeared since BookReserved. Chronicle materializes the events and copies the scope dictionary when you create the result, then submits both together. A failed constraint, concurrency check, or append fails the reactor partition; Chronicle never splits the return into partial appends.

A scope entry with ConcurrencyScope.NotSet, or a missing entry for an event source id in the batch, asks the configured concurrency strategy to resolve that source’s scope. Use ConcurrencyScope.None when you explicitly want no check for a key. Chronicle passes every other scope through unchanged.

The event list preserves the order you supplied to the append operation. That does not impose a global processing order on observers: events targeting different source partitions can be observed independently. The scope dictionary also holds one scope per EventSourceId key; it cannot represent multiple independent scopes under the same key.

Set metadata once on the reactor type so every returned event inherits it automatically.

Implement this interface to supply a custom EventSourceId for all side-effect events from this reactor:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.Reactors;
public class WarehouseEventSourceReactor(string warehouseId) : IReactor, ICanProvideEventSourceId
{
public EventSourceId GetEventSourceId() => warehouseId;
public StockDecreased BookReserved(SideEffectsBookReserved @event, EventContext context) =>
new(@event.Isbn, 1);
}

Implement this interface to attach a Subject (e.g. a user or principal) to appended events:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.Reactors;
public class OrderReactor(string userId) : IReactor, ICanProvideSubject
{
public Subject GetSubject() => new(userId);
}

Implement this interface to specify a runtime EventStreamId:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.Reactors;
public class TenantReactor(string tenantId) : IReactor, ICanProvideEventStreamId
{
public EventStreamId GetEventStreamId() => tenantId;
}

[EventStreamType] and [EventSourceType] Attributes

Section titled “[EventStreamType] and [EventSourceType] Attributes”

Apply these attributes to the reactor class for a compile-time stream or source type:

using Cratis.Chronicle.Events;
using Cratis.Chronicle.Reactors;
[EventStreamType("warehouse")]
[EventSourceType("product")]
public class WarehouseMetadataReactor : IReactor
{
public StockDecreased BookReserved(SideEffectsBookReserved @event, EventContext context) =>
new(@event.Isbn, 1);
}
MetadataPriority
EventSourceIdICanProvideEventSourceId -> eventContext.EventSourceId
EventStreamIdICanProvideEventStreamId -> [EventStreamId] attribute -> null
EventStreamType[EventStreamType] attribute -> null
EventSourceType[EventSourceType] attribute -> null
SubjectICanProvideSubject -> null

Extend the pipeline by registering a custom IReactorSideEffectHandler:

using Cratis.Chronicle;
using Cratis.Chronicle.Reactors.SideEffects;
using Cratis.Monads;
using Microsoft.Extensions.DependencyInjection;
public record MySpecialResult;
public class MyHandler : IReactorSideEffectHandler
{
public bool CanHandle(ReactorContext reactorContext, object value) =>
value is MySpecialResult;
public bool CanHandle(ReactorContext reactorContext, IEventStore eventStore, object value) =>
CanHandle(reactorContext, value);
public Task<Result<ReactorSideEffectFailure>> Handle(
ReactorContext reactorContext,
IEventStore eventStore,
object value)
{
return Task.FromResult(Result.Success<ReactorSideEffectFailure>());
}
}
public static class ReactorSideEffectRegistration
{
public static void Add(IServiceCollection services)
{
services.AddSingleton<IReactorSideEffectHandler, MyHandler>();
}
}
Return typeHandler invoked
TEventEventResultHandler — appends single event to the triggering/reactor event source id
Task<TEvent>EventResultHandler
IEnumerable<TEvent>EventsResultHandler — appends each event
Task<IEnumerable<TEvent>>EventsResultHandler
EventForEventSourceIdEventForEventSourceIdResultHandler — appends to the event source id carried by the value
Task<EventForEventSourceId>EventForEventSourceIdResultHandler
IEnumerable<EventForEventSourceId>EventsForEventSourceIdResultHandler — appends all as one transaction
Task<IEnumerable<EventForEventSourceId>>EventsForEventSourceIdResultHandler
EventsWithConcurrencyScopesEventsWithConcurrencyScopesResultHandler — appends its ordered events and scopes as one transaction
Task<EventsWithConcurrencyScopes>EventsWithConcurrencyScopesResultHandler
IEnumerable<object> mixing events and EventForEventSourceIdMixedSideEffectsResultHandler — bare events use reactor metadata, each EventForEventSourceId keeps its own; all appended as one transaction
void / TaskNo side effects appended

If a side-effect append fails, Chronicle marks the reactor partition as failed. Fix the underlying cause and retry or rewind the observer to continue processing.