You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Hit save.
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.
Check your database - the service_sla table looks correct, with 300 rows for the given SLA ID.
Clear cache.
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.
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.
The text was updated successfully, but these errors were encountered:
Environment
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:
service_sla
table looks correct, with 300 rows for the given SLA ID.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.
The text was updated successfully, but these errors were encountered: