void-ptr974 commented on PR #26184: URL: https://github.com/apache/pulsar/pull/26184#issuecomment-4975086769
I think we should distinguish `markDeletePosition == lastPosition` from `markDeletePosition > lastPosition`. The problematic case is when the cursor is ahead of the ledger last position, for example: - `markDeletePosition = 101:-1` - `lastPosition = 100:9` This can happen when the cursor has consumed the previous ledger and has been advanced to the beginning of a new empty ledger. In that case, constructing `(101:-1..100:9]` is invalid, and returning `0` backlog is reasonable. But `markDeletePosition == lastPosition` is a normal caught-up state. For example: - write messages up to `100:9` - cursor marks delete at `100:9` - now `markDeletePosition = 100:9` and `lastPosition = 100:9` There is no backlog, so `getEstimatedSizeSinceMarkDeletePosition()` should return `0`, not throw. With the current `>=` check, this equality case can enter the “ahead” branch and throw if the last ledger exists and is not empty. Could we handle equality as `0` directly and only treat `markDeletePosition > lastPosition` as the special ahead-of-last-position case? A regression test for the caught-up case would also help. -- 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]
