# Bug OP-11128 - Multiples Identicals Webhooks are sent for each WP change applied, not considering the Aggregated WorkPackage Journal

Project: OpenProject
Status: closed
URL: https://community.openproject.org/work_packages/OP-11128

## Open points

_No work packages_

## Details

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | High |
| Module |  |
| Target versions | 12.3.2 |
| Observed in versions | 12.2.0 |
| Sprint | 12.3.2 |
| Backlog bucket |  |
| Bug found in version (deprecated) | 12.2.x |
| Found in mobile app version |  |
| Follow-up feedback e-mail |  |
| Requires doc change | No |
| Accessibility | No |
| Pull preview |  |
| List |  |
| Labels |  |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers |  |
| Designer |  |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Planning

| Attribute | Value |
| --- | --- |
| Relevance |  |

## Costs

| Attribute | Value |
| --- | --- |
| Votes |  |
| Work |  |
| Labor costs |  |

## Description

### Steps to reproduce

1.  Login as an admin user
2.  Set a new webhook for events "work\_package:created" and "work\_package:updated"
3.  Change something in a work package and keep in mind the number of changes you made (all this changes are aggregated in the same journal, for each change the "lock\_version" parameter of the WP are incremented by 1, correct behavior)
4.  Don't touch more the WP and wait for the webhooks after the "journal\_aggregation\_time\_minutes" period (in realty wait for a period equal to the "journal\_aggregation\_time\_minutes" after the first change you made, to receive the first webhook)
5.  Notice that **you receive**, in different moments, **a number of webhooks equal to the number of changed you made, but with the same identical "request\_body"** (same WorkPackageRepresenter, the number of webhooks sent is equal to the difference between the last "lock\_version" and the first "lock\_version")

### What is the buggy behavior?

  - You receive, in different moments, a number of webhooks equal to the number of changed you made, but **with the same identical "request\_body"** (same WorkPackageRepresenter)
  - Seem there is not way to understand via API if a webhook is a duplicate of a previous one, I try to get the activities (/api/v3/work\_packages/{wp\_id}/activities) in the routine that receive the webhooks, but correctly all the changes you made are aggregated like one activity, in the way are saved in the journal table on database. To avoid duplicated webhooks, by my side, I need to develop a stateful version of that routine to keep in mind the "lock\_version" already processed for each WP and discard the nexts to avoid sent the same e-mail different times (now each webhooks start a separate stateless routine that sent some mail according to some filters).

### What is the expected behavior?

1.  I'm expecting to receive only one webhooks call per aggregated journal, like in previous versions.
2.  (alternative) I'm expecting to receive differents request\_body, one per change you made (I think this info is not present in your database because all the changes are directly aggregated and you loose the different "activities" details, and anyway is not the best expected behavior)

### Important note

I suspect that with the release of the notification center, the way you manage the AGGREGATED\_WORK\_PACKAGE\_JOURNAL\_READY event is not correct any more. I see that the notifications are immediately saved in the notification table to permit the users to see the red counter in the frontend. Probably each change overwrite the previous one in that table, if in the same journal, so the notifications are not duplicated and the users receive only one notification per journal.

The same event, if im not wrong, is the trigger to check if a webhook for this event has to be sent. The relative event will be queued immediately (I can't understand where, in the database I not found any clue) and every time you change something, and not only at the end of the "journal\_aggregation\_time\_minutes". This behavior make the system sent more times the same "logical" aggregated change like a webhook, and is a different behavior with respect to what is saved in the Journal table.

### **Logs**

I'm checking the "webhooks\_logs" table in database to check the request\_body sent for each webhook.  
I'm checking the "journals", "work\_package\_journals", and "work\_packages" table to understand how the changes are saved.

### Environment information

**OpenProject installation type**

- [ ] Hosted cloud edition
- [x] Packaged installation
    - Ubuntu
- [ ] Docker All-in-one container
- [ ] Docker-compose installation
- [ ] Other (please specify)

**OpenProject version**

v12.2.3

**Browser**

- [x] Chrome, but I think doesn't matter in this bug.
- [ ] Firefox
- [ ] Safari
- [ ] Mobile Safari
- [ ] Other (please specify)

**Language**

Italian, but I think doesn't matter in this bug.