hubcio commented on issue #3635: URL: https://github.com/apache/iggy/issues/3635#issuecomment-5204358228
good repro, thanks. one thing i want to change in the plan: forget backward compat. we are before 1.0 and i'd rather break the ffi now than drag this design along for years. so no versioned v2 api, no keeping old symbols, just change the contract. about the state advancing while iggy was down - i looked into it, keep it in this issue. poll() attaches state to every batch, including empty ones. after a failed send the next poll comes back empty, producer.send with an empty vec returns ok without any network call, and the runtime happily saves the already advanced state. i think tthats why the #3321 guard didnt help. it also means the loss is permanent even in plain offset mode. cdc has it even worse, pg_logical_slot_get_changes consumes the slot during poll, so there the data is gone on the postgres side already. for ordering i'd do: poll returns batch + staged state and commits nothing, runtime sends and waits for confirmation, saves state, then acks the plugin, and only then the plugin advances its cursor and runs staged deletes/marks. please list all crash windows in the design doc and make sure none of them can lose rows, duplicates are fine. nack and timeout should both lead to redelivery. one in-flight batch sounds good, btw the poll->send channel is unbounded today so we get backpressure for free with this. separate prs work for me, ffi + runtime first, then postgres migration with a kill-server regression test. do you want to design the fix here (under this issue) first, or u want to jump straight into impl? btw: note that send_messages API has changed in https://github.com/apache/iggy/pull/3781 - now we return the base offset of batch that was appended in partition - it's implemented only for `core/server-ng`, for old `core/server` it's artificially added in the SDK. it's just WA... because in future, code in core/server will be superseded by core/server-ng (iggy server binary with clustering via viewstamped replication). -- 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]
