Defect #33769
When creating more than two identical attachments in a single db transaction, the first one always ends up unreadable
Status: | Closed | Start date: | ||
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | % Done: | 0% | ||
Category: | Attachments | |||
Target version: | 4.0.8 | |||
Resolution: | Fixed | Affected version: |
Description
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.
Related issues
Associated revisions
When creating more than two identical attachments in a single transaction, the first one always ends up unreadable (#33769).
Patch by Jens Krämer.
History
#1
Updated by Go MAEDA almost 2 years ago
- Target version set to 4.0.8
Setting the target version to 4.0.8.
#2
Updated by Go MAEDA almost 2 years ago
- Duplicated by Defect #28440: After commit missing file added
#3
Updated by Go MAEDA almost 2 years ago
- Tracker changed from Patch to Defect
- Status changed from New to Resolved
- Assignee set to Go MAEDA
- Resolution set to Fixed
Committed the fix. Thank you for your contribution.
#4
Updated by Go MAEDA almost 2 years ago
- Status changed from Resolved to Closed