Deduplication Creating One Duplicate After Item Closed

[jacobappleton-orbis]

Hello, the deduplication logic appears to have a bug.

To reproduce:

1. Create an alert that runs every minute, with deduplication turned on, excluding the status Done
2. Wait for a couple of comments to be added to the first ticket
3. Close the ticket

The add-on will create a new ticket, then another new ticket and then start assigning comments to the second new ticket. We now end up with one floating duplicate.

Please let me know if you require any further information to reproduce this issue.

Thanks, Jacob

[guilhemmarchand]

Hi @jacobappleton-orbis !

Thanks for reporting, checking this. I have sent you a collaborator invite on the repo if you are interested in.

Guilhem

[guilhemmarchand]

In between I have working on unit testing and came up with an app containing the biggest and more complex use cases, I will push this anytime soon.

[jacobappleton-orbis]

Happy to be a collaborator! Looking forward to your update and happy to help test/refactor, etc.

[guilhemmarchand]

Nice @jacobappleton-orbis! Appreciate.

Agreed on the issue, I could re-produce it too, working on it

[guilhemmarchand]

The issue stands here:

                # Store the md5 hash of the JIRA issue in the backlog KVstore with the key values returned by JIRA
                jira_creation_response_json = json.loads(jira_creation_response)
                jira_created_id = jira_creation_response_json['id']
                jira_created_key = jira_creation_response_json['key']
                jira_created_self = jira_creation_response_json['self']
                helper.log_debug("jira_creation_response_json:={}".format(jira_creation_response_json))

                record_url = 'https://localhost:' + str(splunkd_port) \
                             + '/servicesNS/nobody/' \
                               'TA-jira-service-desk-simple-addon/storage/collections/data/kv_jira_issues_backlog'
                headers = {
                    'Authorization': 'Splunk %s' % session_key,
                    'Content-Type': 'application/json'}

When an issue is added to KVstore collection, the _key is generated automatically, while we later on rely on this _key to be equal to the MD5 hash value to state if an issue exists in the backlog collection or not.

[guilhemmarchand]

@jacobappleton-orbis The fix is now in testing (from branch 1.0.20), feel free if you have a chance to verify.

The issue was the creation of the entry in the backlog when the jira dedup found was true, which was not expected initially and was letting Splunk to be deciding from the _key value, which in our context needs to be the MD5 hash of the issue.

[jacobappleton-orbis]

Thanks @guilhemmarchand , I’ll take a look today or tomorrow morning.

Appreciate the quick fix!

[guilhemmarchand]

Hi @jacobappleton-orbis ! Did you have a chance to double check the fix?

Given that it is affecting a functionality, I'd like to push the new release ASAP to Splunk Base.

Thanks ;-)

[jacobappleton-orbis]

I've reviewed the code. When you tested locally, did it resolve the issue?

[guilhemmarchand]

@jacobappleton-orbis Yes sure it does, Tests are all successful. Was only asking if you had anything you wanted to review, or having a double pair of eyes All thank you so much for reporting