nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Handling issue deletion in listener that listens for changes in links

Matt Whitaker_3rxlpn

Hi,

I have a bit of an issue with deleting issues in a listener that I have been debugging. I believe there is some kind recursion going on in the function below.

To outline I have a listener that listens for when link created and then updates a field on one of the issues where the link is (depending on the outward and inward wording of the link). This works perfectly until I come to delete the issue. When deleting an issue it seems to fire the link deletion event first and then of course it tries to update an issue which jira is deleting which is where I assume it gets stuck. This then breaks the db and the issue is stuck for ever. Is there a way I can stop the issue from being updated when it is currently being deleted and how can I tell when this is happening?

Many thanks for any help given in advance.

Accepted answers

All comments

Danyal Iqbal

Never delete an issue, cancel it or close it or something else. It is a bad practice. Reconsider your workflow!

Matt Whitaker_3rxlpn

Hi,

Thanks for the reply, I don't want to rely on process to cover holes in my code. But yes this is an edge case I understand this is not something users do on a regular basis.

Zoi Raskou

Hi, echoing the previous comment it's generally bad practise to delete issues.

If however you need to delete them you can add a clause in you listener. I am assuming you are using Scriptrunner so unless I am missing something you can remove the issue link deleted from the list of events that trigger it.

Alternatively something like if (!linkedIssue) return will also unblock your script.

Danyal Iqbal

Hi Matt,

You could use an if else block to make sure that the update code is not executed when a deleted link event is detected.

Regards,

Matt Whitaker_3rxlpn

Hi,

That was my first thought however after looking into the deletion logic I can see that there is a certain 'flow' that happens when deleting an issue which is why my first crack i.e trying to catch the ISSUE_DELETE_ID event didn't work. From this post https://community.atlassian.com/t5/Answers-Developer-Questions/How-to-retrieve-issue-links-in-delete-issue-event-listener/qaq-p/477337 it seems that the removal of links and therefore the event for the removal of links is called before the actual ISSUE_DELETE event:

- save issue(just like "table row") self, customFieldValues and watchers in event data object
- removeWorklogs (it meant, what you not get not only link, but worklogs too)
- remove sub-tasks
- remove links (!!!!!)
- remove history
.....
- dispatch Event (with event data object from first point)

Matt Whitaker_3rxlpn

Hi,

Ok, this is where I must have missed something I'm aware that some events helpfully come for free with others, as seen above, I'm just wondering as this must be an issue people come across that the events are fired in the 'wrong' order for the implementation I have. I almost want to be able to just cut off the script if it takes too long...

The problematic line is:

cfAutoLinkField.updateValue(null, sourceIssue, new ModifiedValue(sourceIssue.getCustomFieldValue(cfAutoLinkField), null), changeHolder)

Which is trying to update the field when the deletion logic is trying to delete it which I assume causes an internal error.

Many thanks for the help,

Matt

Matt Whitaker_3rxlpn

If anyone comes across this issue in the future this is eventually how I have solved it. I have taken it that having a script that looks for an issue delete event cannot try to update the issue on this event without it looking when you finally try and delete the issue. for this reason purely so you don't lock the JIRA DB and cause issues I have given the update command a 5 second time out and used java concurrent to handle the deletion in a different thread that I eventually cut if it times out. Is this a nice solution that I'm suggesting? Probably not. But in the absence of other ways of achieving this I have gone with this option. I would appreciate if anyone can tell me if this is a complete no go area and I will remove. But this is all I have found. I don't attach the code for this reason.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

listener

adaptavist