Problem

• Every approval change on a page or work item rewrites its approval property, which the approval searches and the workflow conditions read. The change reads the property, merges itself in and writes it back. Confluence refuses the write with 409 when another change wrote the property in between. AP-2471 retries once, so a third parallel change, or a retry that loses again, fails the whole change. On QA a start through the Web API (POST /webapi/v2/approvals) on one page failed with "Property approvalPathQa on 2527399438 was changed concurrently" and was rolled back.

• AP-2274 serializes approval changes per page or work item with a lock that every change must take. Decisions, starts from the workflow post-function, Automation and Rovo, and reruns after a page change take it. These changes do not:

  1. Starts from the approval panel and the Web API (v1 and v2), reruns from the Confluence panel and relaunches after validity expiry.

  2. Bulk delete and archive: bulk actions on the approvals list, Web API delete and archive, and the Automation delete and archive actions.

  3. Deleting and archiving one approval from the panel.

  4. The property refresh after a step reassignment, after a decision deadline or validity expires, and after a work item field change updates dynamic steps.

• Running unserialized, a change can also build the property without a parallel change that is not committed yet. The property then misses an approval in progress or its pending approvers until the next change on that page or work item. In Jira the work item property has no version, so the later write silently replaces the earlier one instead of failing.

Change

• Each of the changes 1–4 takes the page or work item lock before it touches the approval, like decisions do. Changes on one page or work item run one after another; changes on different pages and work items still run in parallel.

• Delete and archive read the approval again once they hold the lock. An approval that was decided in the meantime leaves the approved or rejected part of the property, and one that was already deleted or archived in the meantime is left as it is.

• When the property refresh after a reassignment, an expiry or a field change cannot reach Jira or Confluence, the pending approvers stored by the app are still saved.

• The retry on 409 from AP-2471 stays.

Acceptance criteria

• Several approvals started at the same time on one Confluence page or Jira work item through the Web API all start; none fails with "was changed concurrently".

• After parallel starts, deletes, archives and decisions on one page or work item, the approval searches for approvals in progress and for pending approvers find that page or work item exactly as its approval panel shows it.

• Changes on different pages or work items do not wait for each other.

Manual tester notes

• Confluence and Jira, with a Web API key: send five POST /webapi/v2/approvals requests at once for the same page or work item (for example a Postman runner with parallel requests, or curl with xargs -P 5). All five return the new approval and the panel shows five approvals in progress. Repeat a few times; no request fails.

• After that, select the five approvals on the approvals list and archive them in one bulk action while someone approves one of them from the panel. The panel and the approval searches (pending on me, in progress) agree on what is left.

• Start one approval from the panel and one from the Web API on the same page at the same moment: both start.

• Jira: reassign a step from the panel and change a work item field used by a dynamic step right after it; the pending approver searches show the new approvers.