mlevkov commented on PR #3795: URL: https://github.com/apache/iggy/pull/3795#issuecomment-5442683755
Following up so this does not end here. Closing this was right: #3855's one-batch-in-flight rule means the forwarding channel cannot grow, which was the whole premise. But that only holds while the runtime answers inside the SDK's 30s `BATCH_RESULT_TIMEOUT`. Past it `handle_messages` stops waiting, NACKs, increments the batch id and polls again, so the timed-out batch stays in the channel and the next one joins it. `MAX_CONSECUTIVE_NACKS = 5` looks like the ceiling, but `apply_batch_result` resets the counter on any `Ack`, so an alternating ack/timeout run never trips it. That is the half of this PR that outlived its premise, and it was tracked nowhere once this closed. It is now #3981, together with the second-order finding from the same review: a batch that times out and then sends successfully has its ack refused on a `take_pending_batch` id mismatch, so the runtime logs a delivery failure, bumps the error counter, and marks the connector errored for a batch that reached Iggy intact. #3941 covers the other end of the same policy, the five-NACK stop and its invisibility. If `BatchPolicy` becomes configurable there, `result_timeout` is the third knob. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
