# Does in-flight request breaker really track writing requests?

**URL:** <https://discuss.elastic.co/t/does-in-flight-request-breaker-really-track-writing-requests/378330>\
**Category:** Elasticsearch\
**Created:** [May 20, 2025, 8:48am UTC](https://discuss.elastic.co/t/does-in-flight-request-breaker-really-track-writing-requests/378330 "2025-05-20T08:48:02Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![vsop\_479](https://avatars.discourse-cdn.com/v4/letter/v/6f9a4e/32.png) [@vsop\_479](https://discuss.elastic.co/u/vsop_479)\
**Post date:** [May 20, 2025, 8:48am UTC](https://discuss.elastic.co/t/does-in-flight-request-breaker-really-track-writing-requests/378330/1 "2025-05-20T08:48:02Z")

</div>

According to the comment above `CircuitBreaker#IN_FLIGHT_REQUESTS`:

```auto
    /**
     * The in-flight request breaker tracks bytes allocated for reading and
     * writing requests on the network layer.
     */
    String IN_FLIGHT_REQUESTS = "inflight_requests";

```

The in-flight request breaker tracks both reading(receiving) requests and writing(sending) requests, but I only find it is used to track reading (receiving) requests in `Netty4MessageChannelHandler#channelRead`(transport level) and `Netty4HttpPipeliningHandler#channelRead`(http level).

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [May 20, 2025, 11:09am UTC](https://discuss.elastic.co/t/does-in-flight-request-breaker-really-track-writing-requests/378330/2 "2025-05-20T11:09:50Z")

</div>

I think you're right, this only tracks inbound requests.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [May 20, 2025, 2:25pm UTC](https://discuss.elastic.co/t/does-in-flight-request-breaker-really-track-writing-requests/378330/3 "2025-05-20T14:25:34Z")

</div>

Moving your [follow-up question](https://github.com/elastic/elasticsearch/pull/128192#issuecomment-2894238820) here:

> I am wondering if we should track writing requests by enhancing `CircuitBreaker#IN_FLIGHT_REQUESTS` or adding a new breaker.  
> Normally, it's ok to keep these writing requests untracked. But there may be some case which need many memory to send request, e.g. A coordinator send `ShardSearchRequest` to many nodes, or master send clusterstate to many nodes.

Eh maybe. We used to use the `requests` breaker for this but stopped. I'm not sure it really helped much. Indeed I wonder if the `inflight_requests` breaker even makes much sense any more.

In the two specific cases you called out, the outbound `ShardSearchRequest` overhead should be pretty trivial following [Introduce batched query execution and data-node side reduce (#121885) by original-brownbear · Pull Request #126563 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/pull/126563), and the cluster state the master sends out is already using shared buffers so should be manageable too. At least, there's not really much point in throwing a `CircuitBreakingException` on the master if it can't allocate a buffer for the outbound cluster state, because that will also cause an outage just as if the master went OOM. Instead we should do [Limit cluster state transport message sizes · Issue #124068 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/issues/124068).