GNOME Bugzilla – Bug 378638
log replay creates two transactions from a single logged transaction
Last modified: 2018-06-29 21:17:02 UTC
Please describe the problem: In the attached file the last but one transation makes the account balance incorrect. The value of the transation is substracted twice (6400) instead of once (3200). This has happened after gnucash crash and replaying the logfile. Please fix the bug and tell me how to repair my file... Steps to reproduce: 1. open the attached file 2. check the "eKonto" account Actual results: account balance is incorrect Expected results: balance is calculated properly. Does this happen every time? yes Other information:
Created attachment 77076 [details] example file illustrating the problem
deleting the dubious transaction just shifts the problem one transaction above
Hm, the problem appears to be a duplicated transaction... But the transaction isn't just duplicated, it shares the same GUID! This is probably a bug in the log replay, where you chose the not-most-recent log and it wound up re-creating an existing transaction without checking that the transaction already exists. One is the transaction with GUID ae0061793976f26ea1cf249051162466 -- if you uncompress your file and look for this, you'll see the transaction listed twice. Txn 7224b09372434b12ec3f3a7465ccc4c6 is also duplicated. So, the way to fix your data file is to remove one copy of each of these two transactions. Just look for a <trn:id type="guid">... tag with those GUIDs. But yeah, log replay shouldn't blindly re-create an existing transaction... And perhaps C&R should check this as well.
I was able able to fix my file using those tip. Thankyou very much! I will leave this bug open so you can decide how to deal with it.
yeah, the bug is that the replay code doesn't check before allocating a new object. It should see if one already exists first, and if it does it can either throw an error, or just merge into the existing. I think throwing an error is probably better, something like "Trying to create an object that already exists. Maybe you have already replayed this log file?"
re-summarizing; lowering severity.
Reassigning to XML backend since this isn't a register problem.
*** Bug 515502 has been marked as a duplicate of this bug. ***
Please see the dup bug, too. It has screenshots of GnuCash's apparently "funny math". > the bug is that the replay code doesn't check before allocating a new > object. Well, that means anybody who would replay any log file more than once, which easily happens given that you need to replay a few dozen log files in order to restore a few hours work, would run into this bug. And it's severe: It silently corrupts the data - you only notice, at best, that the calculations end up somehow wrong, but it's hard to drill down. And the problematic transaction is not even visible. This costed me me several hours to recover my finance books. That was totally avoidable, given that this bug was known and acknowledged years before I ran into it. This is not very comforting for an application which is central to business and personal finances. Data corruption bugs like these must be fixed in days, not years. So, there are 2 bug and fixes needed: - Avoid adding the same transaction twice, as Derek said but also: - If there are 2 transactions with the same IDs, everything identical, remove the duplicate. If they have the same IDs, but differ in content, change ID so that both show, and show error dialog and point user to them to fix them (consider that there may be many such transactions found at once. If UI is too hard, just write report in text file and show a dialog pointing to the file.)
I have fixed part one in r19243. The cause of this problem had to do with read-only transactions. Firstly, if the replay log had a delete entry for a transaction that is marked as read-only in the book, the delete failed. Secondly, replay of an existing transaction was implemented as delete-create again. These two combined would result in duplicate entries in the book for when an existing read-only transaction got replayed (although only the original would remain read-only). So this issue popped up with - reconciled transactions - transactions belonging created via the business logic. I have chosen to override the read-only state of transactions when replaying, and issuing a warning in the logs. The code is in string-freeze currently, so I can't add user feedback. While working on it, I came to the conclusion there are still other issues with log and log replay (like changes in accounts and business objects aren't logged so can't be replayed, resulting in a potentially inconsistent book). So I can only advise to be very careful when using it and verify if the result is what you like.
I just checked in r19689 which cleans up the calls to xaccTransBeginEdit and xaccTransCommitEdit in the log replay code. Change r19243 (perhaps accidentally) deleted a call to xaccTransBeginEdit resulting in a crash if you replayed a log that deleted a transaction.
Thanks for catching that.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=378638. Please continue processing the bug there and please update any external references or bookmarks.