Repository navigation
Validation
Stateflows validates incoming class-based event payloads before dispatching them to a Behavior. The default validator applies .NET Data Annotations, including validation attributes on the event and its properties. If validation fails, the event is not processed and its result carries validation errors.
AddStateflowsClient registers the built-in AttributeValidator. It uses Validator.TryValidateObject with property validation enabled. For example:
using System.ComponentModel.DataAnnotations;
public sealed record CreateAccount(
[property: Required]
[property: EmailAddress]
string Email);Validation is applied to class payloads; non-class payloads bypass the validator pipeline. A class event is checked before its Behavior processor receives it. Validation results are returned as part of the send/request result rather than being delivered as a normal Behavior event.
Implement IStateflowsValidator to apply application-specific rules. It receives the event and a mutable list of ValidationResult objects; return false when the event is invalid. Register the implementation on the Stateflows builder:
using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Threading.Tasks;
using Stateflows;
using Stateflows.Common;
public sealed class CreateAccountValidator : IStateflowsValidator
{
public Task<bool> ValidateAsync<TEvent>(
TEvent @event,
List<ValidationResult> validationResults)
{
if (@event is not CreateAccount request)
{
return Task.FromResult(true);
}
if (request.Email is not null &&
request.Email.EndsWith("@blocked.example", StringComparison.OrdinalIgnoreCase))
{
validationResults.Add(new ValidationResult(
"This email domain is not allowed.",
new[] { nameof(CreateAccount.Email) }));
return Task.FromResult(false);
}
return Task.FromResult(true);
}
}Register the validator in startup code:
services.AddStateflows(stateflows => stateflows
.AddValidator<CreateAccountValidator>()
.AddStateMachines(machines => machines
.AddStateMachine<AccountWorkflow>()));Validators are additive: the built-in Data Annotations validator and every registered IStateflowsValidator participate. See FluentValidation for the extension that adapts FluentValidation rules into Stateflows validation results.
A custom validator must tolerate malformed or missing values: a previous validator's failure does not stop the remaining validators. In this example, Data Annotations reports a missing email; the custom validator checks the domain only when an email is present.
Home page Support Code licensed under an MIT-style License. Documentation licensed under CC BY 4.0. © by Mikołaj Milewski, 2026
Overview
Installation
Runtimes
Orleans runtime
Concepts
Events and Structural Events
Messaging Patterns
Validation
Scheduling
Observability
Behaviors
Behavior Values
Dependency Injection
Behavioral Groups
State Machines
Concepts
State Identity
In-State Event Deferrals
Evaluation of Transitions
Exception Handling
Building blocks
Regions
States
State
Composite State
Orthogonal State
Final State
Pseudostates
Choice
Junction
Fork
Join
History
Transitions
Transition
Default Transition
Internal Transition
Activities
Concepts
Exception Handling
Implicit Fork and Join
Tokens
Building blocks
Nodes
Action Node
Decision Node
Merge Node
Initial Node
Final Node
Input Node
Output Node
Fork Node
Join Node
Accept Event Action Node
Send Event Action Node
Publish Event Action Node
Time Event Action Node
Data Store Node
Structured Activity Node
Iterative Activity Node
Parallel Activity Node
Flows
Data Flow
Control Flow
Actions
Entities
Fields
Mutations
Projections
Extensions
ClearScript
FluentValidation
JSON definitions
Minimal APIs
OneOf
OpenTelemetry
PlantUML
Scheduling