Latency is one of the few production conditions that is hard to fake well in unit tests. delayAction gives you a deterministic way to drop slowness into any exchange and watch the client react. Combine it with filters to narrow the impact to one endpoint, or with averageThrottleAction to model both startup delay and throughput.
Reach for delayAction when you need to reproduce a slow network or a slow upstream without leaving your laptop. It is the lightest way to verify that a client correctly handles latency, retries, or timeouts.
Typical situations include:
The scope property controls when the delay fires. Use onAuthorityReceived to slow connection setup, responseHeaderReceivedFromRemote (the default) to slow the response, or responseBodyReceivedFromRemote to slow the body. Durations are in milliseconds.
Verifies that the calling client gracefully degrades when the upstream is slow but still functional.
rules:
- filter:
typeKind: HostFilter
pattern: api.internal.example.com
actions:
- typeKind: DelayAction
duration: 2000
Helps reproduce bugs where a client reads the status code quickly but stalls while streaming the body.
rules:
- filter:
typeKind: PathFilter
pattern: /download
actions:
- typeKind: DelayAction
duration: 5000
scope: ResponseBodyReceivedFromRemote
Triggers the delay as soon as Fluxzy knows the destination authority, before the TCP connection completes.
rules:
- filter:
typeKind: HostFilter
pattern: payments.example.com
actions:
- typeKind: DelayAction
duration: 10000
scope: OnAuthorityReceived
Add a latency to the exchange.
Evaluation scope defines the timing where this filter will be applied.
responseHeaderReceivedFromRemote This scope occurs the moment fluxzy has done parsing the response header.
delayAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| duration | int32 | Duration in milliseconds | 0 |
| scope | onAuthorityReceived | requestHeaderReceivedFromClient | dnsSolveDone | requestBodyReceivedFromClient | responseHeaderReceivedFromRemote | responseBodyReceivedFromRemote | copySibling | outOfScope | Define when the delay is applied | responseHeaderReceivedFromRemote |
This filter has no specific usage example
View definition of DelayAction for .NET integration.
This action has no related action
Milliseconds. A value of 1500 means a 1.5 second delay.
Not directly. delayAction takes a fixed value. For random or distribution based latency, generate the rules from a script or use setVariableAction together with several delay rules.
Only at the scope you choose. The default scope delays after response headers arrive, which simulates a slow server. Pick a request side scope to simulate a slow client or slow network upload.
Yes, use averageThrottleAction to cap the bytes per second. Combine it with delayAction when you need both a fixed startup latency and a sustained throughput limit.