-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transaction do_abort_tx request: not found, assuming already aborted. #24468
Comments
@bharathv replication team? |
@vsarunas Based on my reading of the logs, everything is working as expected. There was an expired group transaction which triggered an internal abort of the transaction. Internal aborts (initiated by Redpanda, not client) are treated specially compared to client initiated aborts by bumping the epoch. This is done to fence all further client requests with previous epoch and the client has to init again to make progress. So I believe that resulted in a "FENCED" error when the client attempted to abort again.
What exactly did you restart? Client or the broker? I'd expect the client to init_transactions() again in this case and it should unblock itself. |
@bharathv, the application was restarted but could not complete a transaction. After restart of the broker, application started to work correctly. The issue reproduced again on another system for the same user; but same version v24.2.8. Upgraded now to v24.3.1. Same issue |
Yes, i did, this log line is not a problem.
Thanks, do you have client logs (timestamps and error codes, pre and post RP restart) and a rough pseudo code of what it does? (exception handling) |
Version & Environment
Redpanda version: (use
rpk version
):macOS, Linux VM running a Docker container with rpk 24.2.8.
What went wrong?
rdkafka client was getting rejects "Local: This instance has been fenced by a newer instance" when trying to abort a transaction; (2024-12-06T06:56:02.818413+01:00)
This section of logs look suspicious from the same time as the client reject:
Transaction in
CompleteAbort
state:Restart of rpk cleared up the state and allowed the application to work further.
Full logs
The text was updated successfully, but these errors were encountered: