Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Polly-Contrib/Simmy/llms.txt

Use this file to discover all available pages before exploring further.

The InjectResult<TResult> policy intercepts typed Polly executions and randomly substitutes the real return value with a configured fake result — for example, replacing a successful HttpResponseMessage with a 400 Bad Request. Unlike InjectException, which throws, this policy returns a value, making it the right tool for testing code paths that inspect the result before deciding whether to retry, fall back, or propagate. There is also an overload that injects an exception as a result in a typed context, which is useful when the policy wrapping your call is Policy<TResult>-typed and needs to see a fault surface through the result path rather than as a thrown exception.

Factory method signatures

// Injects a TResult value
InjectOutcomePolicy<TResult> MonkeyPolicy.InjectResult<TResult>(
    Action<InjectOutcomeOptions<TResult>> configureOptions
)

// Injects an Exception surfaced through the TResult policy path
InjectOutcomePolicy<TResult> MonkeyPolicy.InjectResult<TResult>(
    Action<InjectOutcomeOptions<Exception>> configureOptions
)
Both overloads return InjectOutcomePolicy<TResult> and share the same fluent builder pattern. The difference is entirely in what gets injected: a result value of type TResult, or an exception that Polly surfaces within a Policy<TResult> context.

Quick start

1

Create the result to inject

Construct the fake response object that Simmy should substitute for the real call’s return value.
var result = new HttpResponseMessage(HttpStatusCode.BadRequest);
2

Build the chaos policy

Use the fluent builder to specify the injected result, injection rate, and enabled flag.
var chaosPolicy = MonkeyPolicy.InjectResult<HttpResponseMessage>(with =>
    with.Result(result)
        .InjectionRate(0.05)
        .Enabled()
);
An injection rate of 0.05 means roughly 5% of calls receive the fake BadRequest response instead of hitting the real service.
3

Execute through the policy

Run your typed call through the policy. The caller receives either the real response or the injected one.
var response = chaosPolicy.Execute(() => myService.GetData());

Fluent option methods

.Result(value)

Provides a fixed TResult instance to return in place of the real call’s result.

.InjectionRate(double)

A value between 0.0 and 1.0 controlling how often the substitution occurs.

.Enabled() / .Enabled(bool)

Activates the monkey policy. Pass false to deploy without injecting.

Dynamic result generation with a delegate

Supply a Func<Context, CancellationToken, TResult> to vary the injected result at runtime based on the execution context. This is useful when different operations should receive different fake responses.
var chaosPolicy = MonkeyPolicy.InjectResult<HttpResponseMessage>(with =>
    with.Result((ctx, ct) =>
            new HttpResponseMessage(HttpStatusCode.ServiceUnavailable))
        .InjectionRate(0.1)
        .Enabled()
);

Injecting an exception as a result

When your policy is Policy<TResult>-typed (for example, wrapping an HttpClient via HttpClientFactory), the second overload lets you inject a fault that surfaces inside the typed result pipeline rather than being thrown as an unhandled exception.
var chaosPolicy = MonkeyPolicy.InjectResult<HttpResponseMessage>(with =>
    with.Fault(new HttpRequestException("Simulated HTTP failure"))
        .InjectionRate(0.05)
        .Enabled()
);
Use Fault(exception) inside InjectResult when your outer Policy&lt;TResult&gt; is configured to handle that exception type (for example, a retry policy that handles HttpRequestException). The exception travels through the typed policy pipeline so your resilience handlers see it correctly.

Injecting a result vs. injecting an exception

Use InjectResult with .Result(value) when you want to test code that inspects the return value before deciding what to do — for example, retrying on non-2xx HTTP status codes.
// Returns HttpResponseMessage(BadRequest) ~5% of the time
var chaosPolicy = MonkeyPolicy.InjectResult<HttpResponseMessage>(with =>
    with.Result(new HttpResponseMessage(HttpStatusCode.BadRequest))
        .InjectionRate(0.05)
        .Enabled()
);

Async variant

For async/await code, use MonkeyPolicy.InjectResultAsync<TResult>, which returns AsyncInjectOutcomePolicy<TResult> and accepts InjectOutcomeAsyncOptions<TResult>. The fluent builder methods are the same — .Result(), .Fault(), .InjectionRate(), and .Enabled() — except that the delegate overloads for EnabledWhen and InjectionRate return Task rather than plain values.
var chaosPolicy = MonkeyPolicy.InjectResultAsync<HttpResponseMessage>(with =>
    with.Result(new HttpResponseMessage(HttpStatusCode.TooManyRequests))
        .InjectionRate(0.05)
        .Enabled()
);

var response = await chaosPolicy.ExecuteAsync(
    async ct => await httpClient.GetAsync("/api/data", ct),
    cancellationToken
);

Using inside a PolicyWrap

Place the Simmy policy innermost so your outer typed resilience policies — retry on non-2xx, fallback on ServiceUnavailable, etc. — exercise their logic against the injected result.
var policyWrap = Policy<HttpResponseMessage>
    .Wrap(fallbackPolicy, retryPolicy, chaosPolicy);

var response = policyWrap.Execute(() => myService.GetData());
Combining InjectResult with a retry policy configured to retry on HttpStatusCode.ServiceUnavailable is an effective way to verify that retry exhaustion and fallback chains behave correctly under load.

Reference

See Policy Options for the full reference on shared fluent options, including delegate overloads for InjectionRate and EnabledWhen.

Build docs developers (and LLMs) love