Empty by design, noOpAction is the placeholder that keeps rule files honest. Teams use it to pause a rule without losing context, to dry run a new filter before wiring in real behaviour, and to embed inline notes that survive the next refactor of the YAML file.
noOpAction exists for cases where the rule must match something but you do not want any side effect. It is most useful for templating, documentation, and temporary toggles.
Typical uses:
description field so the rule file reads like documentation.Because it pairs naturally with filters, you can use it to confirm a filter is matching the traffic you expect before you wire in a real action.
Replace the action body with a no op so the surrounding filter and comments stay in source control while the rule is paused.
rules:
- filter:
typeKind: HostFilter
pattern: api.internal.example.com
actions:
- typeKind: NoOpAction
description: Temporarily disabled while staging team validates the new endpoint
Run the rule with a no op first, observe which exchanges match in the Fluxzy UI or logs, then swap in the actual action once you are confident.
rules:
- filter:
typeKind: PathFilter
pattern: ^/api/v2/
actions:
- typeKind: NoOpAction
description: Verifying that the v2 path filter matches the expected traffic
An action doing no operation.
Evaluation scope defines the timing where this filter will be applied.
requestBodyReceivedFromClient This scope occurs the moment fluxzy received fully the request body from the client. In a fullstreaming mode which is the default mode, this event occurs when the full body is already fully sent to the remote server.
noOpAction
This action has no specific characteristic
The following examples apply this action to any exchanges
An action doing no operation.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: NoOpAction
description: No operation
View definition of NoOpAction for .NET integration.
This action has no related action
Mostly for documentation and review hygiene. A no op rule keeps intent visible in version control, gives reviewers something to comment on, and avoids the churn of deleting and re adding entries.
The filter still evaluates, so the cost is the same as any matched rule. The action itself does nothing, which means no extra latency once the filter check is done.
Yes, although there is usually no reason to. Most teams use a single noOpAction with a descriptive comment to document why the rule is in place.