mjsax opened a new pull request, #23991: URL: https://github.com/apache/kafka/pull/23991
A standby task, and so a warm-up task, learned the end offset of a changelog only from a restored batch. With nothing to restore -- an empty changelog, or local state already at the end of an idle changelog -- no batch ever arrives. The client then kept reporting an end offset of Long.MAX_VALUE for the task, which the broker reads as an unknown lag. The warm-up task therefore never counted as caught up, and its migration stayed staged forever, holding a warm-up slot. When the restore consumer of a standby task reports a lag of 0 for a changelog without a restore end offset, the changelog reader now also records the end offset, as the last offset like a restored batch does: -1 for an empty changelog. The reported end offset of such a changelog is now one past that last offset, the next offset to fetch, as for the restore end offset of an active task or of a source-topic changelog. A negative end offset would otherwise be summed into Long.MAX_VALUE, and reach custom assignors through the assignor API. A fully restored standby task now reports a lag of 0 instead of -1 per changelog. -- 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]
