Bug - Cache Invalidation when updating SLAs

[dkmonaghan]

Environment

• Znuny version: 7.1.2

Expected behavior

Updating an SLA should clear the cache after the changes are made.

Actual behavior

Updating an SLA clears the cache before the changes are made, resulting in the database and cache being inconsistent.

How to reproduce

Steps to reproduce the behavior:

1. Edit an SLA. We have 300+ services, add them all to a single SLA. We have a busy instance of Znuny. For this example, assume we have added 300.
2. Hit save.
3. The list of services shown in the UI for that SLA will occasionally not show the full 300, but rather the first n services where n is a random number between 1 and 300.
4. Check your database - the service_sla table looks correct, with 300 rows for the given SLA ID.
5. Clear cache.
6. Refresh the "AdminSLA" view. All 300 services now appear.

Additional information

We believe we have identified the code which causes this bug. In Kernel/System/SLA.pm line 694, the cache is cleared.

https://github.com/znuny/Znuny/blob/dev/Kernel/System/SLA.pm#L694

However, the database is still being changed up until line 757. If any part of the Znuny system requests data about the SLAs during the time the code between lines 694 and 757 is running, the cache stores an incomplete representation of the SLAs, resulting in the behaviour show in step 3 above.

We believe that the cache invalidation should be moved from line 694 to what is currently line 757.

[dkmonaghan]

@rkaldung Can I ask which part of this requires clarification, please?

We patched our instance 4 months ago using the proposed fix above (moving the cache invalidation to line 757) and have not had this issue reoccur since.

[hanneshal]

Hi @dkmonaghan
this tag is a tag for internal qa / validation. If we could verify it, then the tag will change. If not it would go back to "waiting for contributor"

Regards