Loading today’s stories
Build1 distinct publisher3 min readPublished
Retries, timeouts and breakers stay unexercised until something fails on cue, and a wrapper around Java 11's HttpClient is a cheap way to arrange that. It also stops well short of the socket layer.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Latency is applied first, then the failure decision [6]. That ordering decides what your test actually measures. Inject 500 ms of delay into a client whose request timeout is 200 ms and the timeout wins, so the synthetic 503 is never observed [19]. Which branch you exercise is a property of the config, not of the code under test, so put the delay and the timeout in the same test and assert on which one fires.
The sample configuration in the post pairs a 0.30 failure rate with 100 to 500 ms of random latency, targeted by a regex against one API host [9]. Seven of every ten matching calls still reach the real service [17], so the dependency has to be up and the test is not hermetic. For breaker work the number is worse: if the breaker opens after five consecutive failures, an independent 0.30 rate produces that run with probability 0.3 to the fifth, about one attempt in 411 [16]. That is why the shortest useful setup the author documents is a failure rate of 1.0 with error status 503, returning a synthetic 503 on every targeted call [7]. A breaker test wants a state machine driven to a known state.
Injected latency is real waiting. The mean of a 100 to 500 ms uniform delay is 300 ms, so 100 sequential matching calls add roughly 30 seconds of wall clock [15].
On the failure path, nothing below java.net.http runs at all. The synthetic response comes back without touching the network [6], which means no connection, no handshake, and no read timeout on a socket that went quiet halfway through a body [18]. The author is explicit that this is not a replacement for a network proxy or a full chaos-engineering platform [10]. What it does replace is the cheap half of failure testing: the mock server edits, the proxy rules, the container networking changes and the one-off test doubles per client abstraction that the author lists as the usual alternative [11].
Two implementation details are worth the read. Cancellation propagates for delayed asynchronous work [4], and the naive version of this schedules a delay task and orphans it when the caller cancels the future. And a delegated call passes the original request and body handler through to the real client [6], so the generic type of your BodyHandler survives and there is no second response-handling path to disagree with production.
Adoption cost is one construction site per client. Something has to give the wrapper a real HttpClient and an immutable config [5], and the sample code closes the wrapper with try-with-resources [12], so it owns a resource with a lifecycle you now have to shut down. The post discloses that AI helped structure and polish the write-up, with the architecture, codebase and implementation decisions the author's own [14]. The config snippets are the part that can be checked either way.
Ranked by verification strength, evidence, and original report placement.
The author built and open-sourced Flaky HTTP, a small Java 11 library for deliberately making HTTP calls less reliable.
The Maven coordinate for the library is com.tapadyuti:flaky-http:1.0.0.
Flaky HTTP is a lightweight wrapper around Java 11's java.net.http.HttpClient.
The library can add fixed or random latency, return synthetic HTTP errors with a configurable probability, target requests using a full-URI regular expression, handle synchronous and asynchronous calls, propagate cancellation for delayed asynchronous work, and run without runtime dependencies beyond Java 11.
The library uses composition: an application gives FlakyHttpClient a real HttpClient and an immutable configuration, and requests whose URI does not match are passed to the real HttpClient.
For a targeted request, latency is applied first, then the client makes a failure decision; if failure is selected it returns a synthetic response without touching the network, otherwise it delegates the original request and body handler to the real client.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
The stopping problem: an LLM rewrite loop that converged on code javac rejected1 distinct publisher
build
A green @DataJpaTest can prove only that Hibernate handed back the same object1 distinct publisher
build
Shared memory in Java: the mmap is the easy half, the descriptor handoff is the work1 distinct publisher
build
One game, two codebases: where parity belongs when you ship native on iOS and Android1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed first-party description, no independent verification
The single source is unusually specific for a launch post: Maven coordinate, configuration snippets, a request-flow diagram, and an explanation of how the synthetic path applies the caller's BodyHandler and completes its BodySubscriber with an empty body. That specificity makes the mechanism checkable in principle, but everything rests on one self-published post by the library's own author, with no independent test, benchmark, review or repository metrics in the cluster, and the supplied body is truncated mid-discussion of body handling.
Release disclosure only
The only adoption signal is the 1.0.0 release itself under a personal Maven group ID. No downloads, dependents, stars, contributors, production deployments or user reports appear anywhere in the supplied material, and the author frames use as tests and local development rather than deployment.
Mostly self-limiting, with mild 'chaos library' framing stretch
The post is candid about scope: it says outright that it is not a replacement for a network proxy or a full chaos-engineering platform, and the described architecture makes the network bypass plain. The residual overstatement is framing - a 'chaos library for Java' that never opens a socket on the failure path - plus two practical limits the author leaves unstated: empty synthetic error bodies and the fact that a short request timeout preempts the injected status code. Nothing in the cluster claims verified reliability outcomes, so the gap stays small.
Author promoting own open-source project
The source is a first-person launch-and-internals post by the library's author on a developer platform, creating a clear reputational and distribution incentive to present the design favourably; the Maven group ID is the author's own namespace. Offsetting factors are the absence of any commercial offering, pricing or paywall in the cluster, an explicit statement of what the library is not, and a disclosure that AI assisted with structuring and polishing the article.
Single first-party source, mechanically clear but uncorroborated
Confidence in the mechanism is reasonable because the described design is internally consistent and the code snippets are concrete, but the cluster has one publisher, one author, no independent corroboration, no repository or license detail, and a truncated body. Derived conclusions about latency cost, consecutive-failure probability and empty error bodies follow from the author's own stated configuration rather than observed behaviour.