Skip to main content
The behavior proactive chaos strategy is designed to inject custom behaviors into system operations right before such an operation is invoked. This strategy is flexible, allowing users to define specific behaviors such as altering the input, simulating resource exhaustion, putting the system in a given state before the actual operation is called, or other operational variations to simulate real-world scenarios.

Configuration

  • Options: ChaosBehaviorStrategyOptions
  • Extensions: AddChaosBehavior

Basic usage

Here are several ways to configure the behavior chaos strategy:

Complete example

Here’s a complete example showing behavior injection with retry:
Chaos strategies should be placed last in the resilience pipeline. This ensures that the custom behavior is executed at the last minute, right before the actual operation is invoked.

Strategy options

Use cases

Behavior injection is useful for:
  • Simulating resource exhaustion: Restart services, flush caches, or simulate memory pressure before operations
  • Testing connection handling: Close database connections or network sockets to test reconnection logic
  • Manipulating state: Put the system in specific states to test edge cases
  • Simulating complex scenarios: Combine multiple actions to simulate real-world failure scenarios
  • Testing cleanup logic: Trigger cleanup operations or resource disposal to verify proper handling
  • Integration testing: Manipulate external dependencies before operations execute

Example scenarios

Restart a Redis cache

Clear application cache

Simulate connection pool exhaustion

Telemetry

The behavior chaos strategy reports the following telemetry events: Here are some sample events:
The Chaos.OnBehavior telemetry event will be reported only if the behavior chaos strategy injects a custom behavior which does not throw an exception. If the behavior is either not injected or injected and throws an exception then there will be no telemetry emitted. Also, the Result will be always empty for the Chaos.OnBehavior telemetry event.

How it works

Normal execution (no chaos)

Chaos execution (behavior injected)

Unlike fault or outcome injection, behavior injection does not prevent the user’s callback from being invoked. The custom behavior is executed before the callback is executed.

Anti-patterns

DON’T: Inject delays using behavior strategy

Don’t use behavior strategies to inject delays. Use the latency chaos strategy instead.

DO: Use latency strategy for delays

Use the latency chaos strategy for injecting delays. It correctly handles synchronous/asynchronous delay executions, cancellations, and provides better telemetry.

Best practices

When using behavior injection in production environments, always:
  • Start with a very low injection rate (e.g., 0.01 or 1%)
  • Ensure injected behaviors are safe and reversible
  • Target only specific test users or tenants
  • Monitor the impact on system resources and performance
  • Keep behavior execution time short to avoid blocking operations
  • Handle cancellation tokens properly in async behaviors
  • Have a quick way to disable chaos injection if needed
When to use behavior injection:
  • When you need to manipulate system state before operations
  • When simulating complex, multi-step failure scenarios
  • When testing resource cleanup and recovery mechanisms
When NOT to use behavior injection:
  • For simple delay injection (use latency strategy)
  • For throwing exceptions (use fault strategy)
  • For returning fake results (use outcome strategy)

Advanced example: Context-aware behavior

This advanced example demonstrates how to:
  • Execute different behaviors based on the operation being performed
  • Use EnabledGenerator to control which operations are affected
  • Properly handle cancellation tokens in async behavior generators