Following up on this now. Seems the consensus now is to fix them in 4.2 and cherry-pick the results back to 4.1 and 4.0 branches.
Thanks for the feedback -Bill On Wed, Nov 5, 2025 at 1:57 PM Chia-Ping Tsai <[email protected]> wrote: > > For sure not ideal, but I tend to prefer to remove the tag for the > affected metrics, and follow what the KIP proposes -- we might also want > to backport the removal to 4.0 and 4.1 -- there will be for sure a 4.1.2 > release; so maybe only 4.0 would be affected. > > +1 to remove them and backport > > > > > > Matthias J. Sax <[email protected]> 於 2025年11月6日 週四 上午2:25寫道： > > > Great catch. It's for sure a tricky one. > > > > We have the incorrect tags for two releases already... Good thing: the > > docs are correct, not mentioning the incorrect tag. > > > > For sure not ideal, but I tend to prefer to remove the tag for the > > affected metrics, and follow what the KIP proposes -- we might also want > > to backport the removal to 4.0 and 4.1 -- there will be for sure a 4.1.2 > > release; so maybe only 4.0 would be affected. > > > > It just seems cleaner to me this way. Curious to hear what others think. > > > > > > -Matthias > > > > On 11/4/25 6:55 PM, Bill Bejeck wrote: > > > Hi All, > > > > > > When working on KIP-1091 > > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1091%3A+Improved+Kafka+Streams+operator+metrics > > >, > > > we mistakenly applied the `process-id` tag to all client-level metrics, > > > rather than just the `client-state`, `thread-state`, and > > `recording-level` > > > metrics as specified in the KIP. This issue came to light while > working > > on > > > KIP-1221 > > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1221%3A+Add+application-id+tag+to+Kafka+Streams+state+metric > > >, > > > which aimed to add the `application-id` as a tag to the `client-state` > > > metric introduced by KIP-1091. > > > > > > > > > To address the issue, we could remove the `process-id` from the metrics > > > that are not intended to have the tag. However, we'd like to initiate > a > > > conversation with the community about the best approach to resolving > this > > > issue. > > > > > > > > > I'm looking forward to your feedback. > > > > > > > > > Thanks, > > > > > > Bill Bejeck > > > > > > > >
