Attachment listeners triggered before the new attachment version uploaded and stored in Confluence

Hello, we discovered the problem: attachment listeners triggered before the new attachment version uploaded and stored in Confluence (we discovered this problem in Confluence, but it probably also exists in Jira). I.e. we try to call attachmentManager.getAttachment(id); in the com.atlassian.confluence.event.events.content.attachment.AttachmentUpdateEvent listener and sometimes it returns attachment, but sometimes returns null for some reason which is probably because the listener has been triggered earlier than attachment has been added to DB. How to deal with this problem? Maybe there is some cache that needs to be refreshed or indexing that needs to complete?

2 Likes

I actually reproduced this in Confluence Data Center, because Confluence server versions are not supported now, so I created a question in the “Confluence” category, see Attachment listeners triggered before a new attachment version uploaded and stored in Confluence, because this question is not Confluence Server specific and maybe not also Confluence DC specific.

Hi Alexey,

This could be because the AttachmentUpdateEvent is synchronous and raised from within a transaction before it is committed. So when you fetch attachment from your listening code, the attachment object is provided from caches. I would recommend you to wrap these usages in a transaction.
If you can delay the execution of your code until the transaction is committed, then it would be nice to perform your actions as part of a new transaction on successful commit of the main transaction. You can try to use SynchronizationManager.runOnSuccessfulCommit(Runnable) to hook in your logic. Also make sure you use a transactional wrapper inside this Runnable so that you get the consistency and don’t get StaleObjects or OptimisticLocking because of hibernate smartness.
Please let me know if you have other questions.

Thanks,
Ganesh
Confluence Developer

1 Like