An Issue in its’ entirety is deleted from the issue view, or deleted using bulk issue delete. For each Issue, we are sent an issue_deleted webhook, along with individual webhooks for every comment/worklog (e.g. an Issue has 3 worklogs and 2 comments, we would also be sent 3
worklog_deleted and 2
comment_deleted. 6 webhooks in total. Webhooks seem to be sent in no specific order
When a worklog is deleted from the issue view, it triggers a worklog_deleted webhook. Only 1 webhook is triggered.
Currently, we attempt to access the Get Issue endpoint. This works for Scenario 2, but will fail for Scenario 1 (As the Issue has been deleted). 2 Attempts to resolve this were:
Attempt to keep a local cache of the Issue ID that had been deleted to know which Issues were no longer existing (Found from the issue_deleted webhook). Problem here was the order of when the webhooks were sent was not consistent, meaning we could handle worklog_deleted webhooks before the issue_deleted webhook)
Using the worklog/deleted endpoint to access worklogs that had been deleted (This would handle Scenario 2, as deleting an issue would not add the worklog ID’s to the endpoint). https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-worklogs/#api-rest-api-2-worklog-deleted-get Problem here, is the endpoint does not show the most consistent ID’s deleted:
This resource does not return worklogs deleted during the minute preceding the request.
My question would be, what is the best solution to ignore the worklog_deleted webhooks from Scenario 1? (We handle Issue Deletion, so those webhooks are not needed. Problem is we still want to handle worklog deleted events when the issue was not deleted, so ignoring worklog webhook types is not a viable solution.)