Found this implementation bug on accident. My archive canister ran out of cycles, when cycles were readded I noticed a duplicate batch of transactions in the archive.
The theory is, it got up to 2k transcations in the ledger and when it tried to send them the archive was out of cycles so it kept trying to send them after every transaction.
Once the archive was refilled, each transaction will try to send that bulk. So you basically need just 2 transactions one after each other with less than 2-3 seconds to get the ledger to send it twice.
I'm working on a solution to backfill and reindex my archive now. To prevent this in the future, I think some kind of check could be added the the append_transactions function that checks for the existing indexes/batch.
Found this implementation bug on accident. My archive canister ran out of cycles, when cycles were readded I noticed a duplicate batch of transactions in the archive.
The theory is, it got up to 2k transcations in the ledger and when it tried to send them the archive was out of cycles so it kept trying to send them after every transaction.
Once the archive was refilled, each transaction will try to send that bulk. So you basically need just 2 transactions one after each other with less than 2-3 seconds to get the ledger to send it twice.
I'm working on a solution to backfill and reindex my archive now. To prevent this in the future, I think some kind of check could be added the the
append_transactionsfunction that checks for the existing indexes/batch.