New Fluxzy v2 just shipped. Electron is out, Tauri is in. gRPC ready, 3x smaller install. Learn more

abortAction Action

Close the underlying TCP or TLS connection for a matching exchange before any response is generated, simulating a hard network failure.

Sometimes a polite HTTP 5xx response is too kind. Real networks fail at the transport layer, and clients that only practice against synthetic 500 errors often crash the first time they meet a true connection reset. The abortAction lets you inject that level of failure deterministically, scoped to whatever filter you want, so your tests cover the messy edge cases as well as the happy path.

When to use this action

Reach for abortAction when you need the client to observe a real transport level failure rather than a clean HTTP response. Unlike rejectAction, which can return a synthetic answer, this action tears down the connection between Fluxzy and the client, so dependent multiplexed streams on the same HTTP/2 connection may also be cancelled.

Typical situations include:

  • Reproducing the behaviour of a flaky network or a sudden ISP drop during automated tests.
  • Blocking telemetry or third party trackers in a way that mimics a real firewall, not a polite 403.
  • Testing how a mobile app handles ECONNRESET mid request, including retry logic and offline UI.

The action evaluates on the requestHeaderReceivedFromClient scope, so the kill happens as soon as Fluxzy has parsed the request line.

Real world examples

Block a tracking domain at the transport level

Drop the connection for all requests to a specific analytics host. The client sees a connection reset, not a polished error page.

rules:
- filter:
    typeKind: HostFilter
    pattern: tracker.example.com
  actions:
  - typeKind: AbortAction

Simulate intermittent failures on a payments API

Combine with a path filter to abort a single endpoint while letting the rest of the API work. Useful for retry and circuit breaker tests.

rules:
- filter:
    typeKind: FilterCollection
    operation: And
    children:
    - typeKind: HostFilter
      pattern: payments.example.com
    - typeKind: PathFilter
      pattern: /v1/charge
  actions:
  - typeKind: AbortAction

Kill all WebSocket upgrades to a specific service

Useful when you want to verify that a client gracefully falls back to long polling when the upgrade handshake never completes.

rules:
- filter:
    typeKind: FilterCollection
    operation: And
    children:
    - typeKind: IsWebSocketFilter
    - typeKind: HostFilter
      pattern: realtime.example.com
  actions:
  - typeKind: AbortAction

Reference

abortAction

Description

Abort an exchange at the transport level. This action will close connection between fluxzy and client which may lead to depended exchanges to be aborted too.

Evaluation scope

Evaluation scope defines the timing where this filter will be applied.

requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client

YAML configuration name

abortAction

Settings

This action has no specific characteristic

Example of usage

The following examples apply this action to any exchanges

Abort an exchange at the transport level. This action will close connection between fluxzy and client which may lead to depended exchanges to be aborted too.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: AbortAction
    description: Abort

.NET reference

View definition of AbortAction for .NET integration.

See also

The following actions are related to this action:

Frequently asked questions

What is the difference between abortAction and rejectAction?

abortAction closes the underlying connection, so the client experiences a transport level error such as ECONNRESET. rejectAction lets Fluxzy answer at the HTTP layer, which is cleaner but less realistic for failure injection.

Does aborting one exchange affect other requests on the same connection?

On HTTP/2 and HTTP/3 the kill happens at the connection level, so streams sharing that connection can also be aborted. On HTTP/1.1 only the current request and any pipelined follow up are affected.

Can I delay the abort to simulate a server that hangs first?

Yes. Chain a delayAction before the abortAction so the connection stays open for a configurable amount of time before Fluxzy drops it.

Will the aborted exchange still show up in captures?

Yes. Fluxzy logs the request that triggered the abort, so you can inspect the headers and timing even though no body was exchanged.

Learn more about Fluxzy rules