When a capture session lasts hours, eyeballing the timeline is not enough. A well placed stdErrAction turns the rule engine into a tiny live monitor that prints exactly the lines you care about, exactly when they happen.
Reach for stdErrAction when you want a rule to emit a diagnostic line that should not mix with normal stdout output. Standard error is the natural channel for warnings, anomalies, and assertion style messages. In CI pipelines and Docker logs, stderr is often colored or treated differently, which makes it easier to spot rule fired alerts at a glance.
Like stdOutAction, the text property accepts {{variable}} substitution, so you can include the exchange host, path, status code, or any variable you defined earlier with setVariableAction. Optionally restrict execution with runScope if the message only makes sense at a particular stage of the exchange.
Use it for sanity checks, "I should never see this" assertions, and to surface unusual conditions during a long capture session.
Stream a stderr line every time a client touches a path scheduled for removal.
rules:
- filter:
typeKind: PathFilter
pattern: /v1/legacy
actions:
- typeKind: StdErrAction
text: "deprecated endpoint hit: {{authority}}{{url}}"
Surface server errors immediately on stderr while leaving the rest of the captured traffic on stdout.
rules:
- filter:
typeKind: StatusCodeServerErrorFilter
actions:
- typeKind: StdErrAction
text: "server error {{statusCode}} from {{authority}}"
Combine with setVariableAction to capture context once and reuse it in the stderr message.
rules:
- filter:
typeKind: RequestHeaderFilter
headerName: X-Debug
headerValue: '1'
actions:
- typeKind: SetVariableAction
name: traceId
value: "{{requestHeader_X-Request-Id}}"
- typeKind: StdErrAction
text: "debug trace id={{traceId}} url={{url}}"
Write text to standard error. Captured variable are interpreted.
Evaluation scope defines the timing where this filter will be applied.
copySibling Applied only on action. The action associated with this scope will copy his value from the triggering filter.
stdErrAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| text | string | ||
| runScope | nullable`1 | When RunScope is defined. The action is only evaluated when the value of the scope occured. |
This filter has no specific usage example
View definition of StdErrAction for .NET integration.
The following actions are related to this action:
Use stderr for warnings, errors, and anything you want to stand out. Use stdout for routine, machine readable output you might pipe into another tool.
Lines are flushed on the fly, which keeps them in the right order with the rest of Fluxzy's stderr output. Long captures with many matches can produce a lot of noise, so scope your filter tightly.
Yes. Any variable available on the current scope is interpolated. Make sure the setVariableAction that defines the variable runs before the stdErrAction in the same exchange.
It pins the action to one specific stage of the exchange, for example responseHeaderReceivedFromRemote. Without it, the action runs at the scope inherited from the filter.