what if persisting into zk fails? Shouldn't we store individualDeletedPosition in both the case Test and Binary

If you're writing in text format, we don't put the current position + individually deleted message ranges into the z-node, but fallback to append to current ledger, where the info is stored in binary format

yes, I understood that on TextFormat we only write in ledger as we can't write in znode. However, I meant: if we are writing in Binary format and on cursor-close if znode-update fails then we won't have latest individualDeletedMessages list in ledger, which is fine and we were not handling it before as well.

Well, that's the same behavior as if the ledger.addEntry() fails, we fail the cursor.close() operation and then it will recover from the cursor ledger next time.

The reason to write directly on the z-node was to speed-up the cursor recovery by needing just one zk read to be completed.

I think we should fail callback rather throwing RuntimeException as it is also being called from non-try-catch-async-callback

Ups, forgot that line that was there for debug

do you think is it fine to combine two ledger/cursor parse method to:
parseInfoFromText(final byte[] data, final Message.Builder builder)

I just wanted to make sure that we first try to deserialize in the format in which we expect the data to be in, to avoid always catching exceptions.

For 1.18 release, when the only option will be to write in binary, we can collapse the 2 method and always try to deserialize first in binary and then in text.

same way here to combine two methods?