Bill Bejeck created KAFKA-21074:
-----------------------------------

             Summary: Add lightweight, client-agnostic Kafka wire-protocol 
fault-injection proxy for integration tests
                 Key: KAFKA-21074
                 URL: https://issues.apache.org/jira/browse/KAFKA-21074
             Project: Kafka
          Issue Type: Improvement
          Components: clients, streams
    Affects Versions: 4.5.0
            Reporter: Bill Bejeck
            Assignee: Bill Bejeck


A lightweight Kafka wire-protocol fault-injection proxy for integration tests. 
Sit it in front of an {{{}EmbeddedKafkaCluster{}}}, point any client’s 
{{bootstrap.servers}} at it, and it can inject error codes, drop connections, 
or blackhole a client — decoding/encoding with Kafka’s own protocol classes so 
it is correct across every wire version (including flexible/tagged-field ones), 
no hand-rolled byte offsets.

Placed in `clients/src/testFixtures` so it is reusable from any module. This is 
internal test infrastructure only so it does not require a KIP.

Fault primitives, each armed with a fluent, deterministic trigger:

- `injectError(apiKey, Errors)` — stamp an error code onto the matching 
response,
  re-serialized at the correct wire version. Supported APIs: `END_TXN`,
  `INIT_PRODUCER_ID`, `ADD_OFFSETS_TO_TXN`, `TXN_OFFSET_COMMIT`, `PRODUCE`, 
`FETCH`
  (extensible by registering a per-API setter).
- `disconnectOn(apiKey)` — drop the connection when the matching response would 
return
  (models the EOS "commit gap"). Works on any API.
- `delayOn(apiKey, Duration)` — hold back the matching response to model a slow 
broker,
  isolated to that one connection.
- `blackholeClient(clientIdSubstring)` — drop all requests from a targeted 
client before
  the broker sees them, so the broker evicts it by session timeout (a 
reversible,
  ungraceful one-node partition).

Shared trigger DSL (`Occurrence`): `once()`, `onCall(n)`, `times(n)`, 
`everyTime()`,
`withProbability(p)`. The deterministic triggers are safe for assertions; 
probability is
chaos-mode only. The proxy never closes sockets unless a `disconnectOn(...)` 
rule fires,
so it is not itself a source of flakiness. Rules can be armed/disarmed live 
from the test
thread and each returns a handle exposing match/fire counts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to