Patch #33769

When creating more than two identical attachments in a single db transaction, the first one always ends up unreadable

Added by Jens Krämer about 1 month ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


Due to the file re-using code running in an after_commit hook, the hooks of any attachments that are created in a common db transaction will be deferred and run one after another after the outer transaction was committed. The existing implementation does not take that into account and as a consequence, when creating more than two identical attachments in a single transaction, the first attachment will end up with a non-existing diskfile.

The attached patch includes a test reproducing the issue and a fix, which consists of using last instead of first when finding an existing attachment to re-use. This way, the selected attachment is consistent across all runs of the hook even if multiple candidates exist. I also added an explicit order call for good measure.

This is a corner case that should never occur in normal Redmine usage - but may occur in 3rd party code that's creating many attachments wrapped in a transaction.

0001-fix-creation-of-multiple-identical-attachments-in-ou.patch Magnifier (1.96 KB) Jens Krämer, 2020-07-26 10:19

Also available in: Atom PDF