Ken Huang

Hello @lianetm @chia7712 , I believe we still cannot abandon the transmission method of ErrorEvent. I’ve noticed that there are other ErrorEvents that are handled differently under various scenarios. Simply...

> Note that metadata errors are the only ones that ended up in this weird situation of having 2 ways to be propagated, so that's what I was hoping we...

> If we say that the CheckAndUpdatePositions events will fail with metadata errors, I expect the poll should fail on addAndGet of that event, triggered from here: we remove the...

I think I have an idea of where the problem lies. With the current approach, the `completeExceptionally` inside `updateFetchPositions` cannot successfully propagate to the application thread.

Hello @apoorvmittal10, @AndrewJSchofield, @lianetm, @kirktrue The current PR has changed the way metadata errors are propagated, switching from `backgroundEventHandler.add(new ErrorEvent(e))` to using `Optional` for transmission. I noticed that in SharedConsumer,...

> One suggestion already: we can simplifying the tweak we had to introduce on the unsubscribe to ignore metadata errors (with your PR, they won't pop out unexpectedly), so I...

Thanks for @kirktrue comments, addressed them

Hello @lianetm I think I still need to confirm with you about the `ShareConsumerImpl`. The original design of `ShareConsumerImpl` relied solely on ErrorEvent to propagate errors, and SharedConsumer does not...

Thanks for @mimaison review, I have addressed comments.

| Benchmark | (numKeys) | (numPossibleKeys) | (numRequests) | (pct50) | (pct75) | (requestRate) | (timeout) | Mode | Cnt | Score | Error | Units | |----------------------------------------------------|-----------|-------------------|---------------|---------|---------|---------------|-----------|-------|-----|--------------------|-----------------|-------| | TestPurgatoryPerformance.testPurgatoryPerformance...