Glpi: GLPI - mysql query loop setting a SLA in a Solved Ticket causing slowdown

[paulopera]

Description

If I try to set a SLA in Solved Ticket after I click save it keeps loading and then show a blank screen or something like error 500 (not always). In the end the action is
executed, it sets the desired SLA in the ticket but it’s too slow the role process, taking sometimes 5+ minutes the hole process. If I’m using a chrome window and
do the steps described and then open a new Incognito Window I can use the GLPI normally but the in the normal one I have to wait while it finishes.

Page(s) URL

In any solved ticket without SLA.

To reproduce

Steps to reproduce the behavior:

1. Go to a Solved ticket without SLA;
2. Click on Time to Resolve;
3. Set any SLA in the list;
4. Wait "forever" or until it shows an error 500 (not always) or a blank screen.

Expected behavior

It should set the SLA almost at real time without a delay or error. I did tried setting a SLA in a Not Solved Ticket and it runs smoothly without errors.

Logs

Attached the mysql.log above;
mysql.log

Find them in mysql.log files under /var/log/mysql/

Screenshots

Screenshot 1: You can see the start of the operation as query # 628;

Screenshot 2: You can see the start of the loop;

GLPI setup

I'm running the GLPI version 9.4.2 on Ubuntu 18.04.2 LTS and both the web and mysql server. Both are up to date too.
I also made a LAB running both GLPI/DB in the same machine and the behavior was the same.
Also did tried running the DB as MariaDB instead of Mysql.

Additional context

I've seen this behavior in previous GLPI versions but always thought it was something about my scenario causing this. In the last 2 versions I saw it was more slow than before so I took a look and saw this query loop described above.

[Armin83]

I had a different strange bug with sla in the past.

the problem exist when the linked calendar have no working days defined.
I changed calender and solved the problem.

[paulopera]

I read something about it but I do have a calendar linked and the working days are defined.

[cedric-anne]

Hi @paulopera ,

Not sure of that, but maybe #5805 fixes this problem. Can you try ?

Regards

[paulopera]

Thanks for the tip @cedric-anne but it didn't worked, I'm still seeing the query loop in the mysql logs and the slowdown.

[paulopera]

@cedric-anne I updated my test GLPI to 9.4.3 using the same DB from my production one and the loop still persists.

[paulopera]

Hey guys does anyone else reported this problem? I still don't know what to do even after the update to 9.4.3. Thanks

[cedric-anne]

Hi @paulopera ,

In #6275 , I fixed 2 errors in the calendar class that may have an impact on SLA escalation times computation. The first one was appearing when opening hours of calendar ends at midnight (24:00). For the second one, I do not remember exactly the context.

Can you try this fix ? Maybe your error is related to one of these errors.

Regards

[paulopera]

@cedric-anne It didn't fix the problem. It still persists the loop in Solved Tickets when I set any SLA

[paulopera]

I know it's not related to this thread but when the search criteria status not solved and SLA time to resolve is/is not set the page shows an error with the debug and if I execute the search the page doesn't shows up.

[trasher]

Please provide full stack tace from GLPI logs

[paulopera]

Here's what the debug mode display when I set the search criteria either is and is not:

Here when the SLA Time to Resolve condition is set to is

[2020-07-25 15:59:56] glpiphplog.CRITICAL: * Uncaught Exception TypeError: Argument 1 passed to Dropdown::addNewCondition() must be of the type array, string given, called in /usr/share/glpi/inc/dropdown.class.php on line 157 in /usr/share/glpi/inc/dropdown.class.php at line 278
Backtrace :
inc/dropdown.class.php:157 Dropdown::addNewCondition()
inc/commondbtm.class.php:3916 Dropdown::show()
inc/commondbtm.class.php:4837 CommonDBTM::dropdown()
inc/ticket.class.php:6789 CommonDBTM->getValueToSelect()
inc/search.class.php:3017 Ticket->getValueToSelect()
ajax/search.php:62 Search::displaySearchoptionValue()

Here when the SLA Time to Resolve condition is set to is not

[2020-07-25 15:59:59] glpiphplog.CRITICAL: * Uncaught Exception TypeError: Argument 1 passed to Dropdown::addNewCondition() must be of the type array, string given, called in /usr/share/glpi/inc/dropdown.class.php on line 157 in /usr/share/glpi/inc/dropdown.class.php at line 278
Backtrace :
inc/dropdown.class.php:157 Dropdown::addNewCondition()
inc/commondbtm.class.php:3916 Dropdown::show()
inc/commondbtm.class.php:4837 CommonDBTM::dropdown()
inc/ticket.class.php:6789 CommonDBTM->getValueToSelect()
inc/search.class.php:3017 Ticket->getValueToSelect()
ajax/search.php:62 Search::displaySearchoptionValue()

If i press the button Search it will break the tickets page displaying no result and not letting me clear the rule. So I need to load a saved search that works and then press the blank button to clear and show the default tickets page:

[cedric-anne]

Hi @paulopera,

[2020-07-25 15:59:56] glpiphplog.CRITICAL: * Uncaught Exception TypeError: Argument 1 passed to Dropdown::addNewCondition() must be of the type array, string given, called in /usr/share/glpi/inc/dropdown.class.php on line 157 in /usr/share/glpi/inc/dropdown.class.php at line 278
Backtrace :
inc/dropdown.class.php:157 Dropdown::addNewCondition()
inc/commondbtm.class.php:3916 Dropdown::show()
inc/commondbtm.class.php:4837 CommonDBTM::dropdown()
inc/ticket.class.php:6789 CommonDBTM->getValueToSelect()
inc/search.class.php:3017 Ticket->getValueToSelect()
ajax/search.php:62 Search::displaySearchoptionValue()

This issue should be fixed by #7768

For the main issue of this thread, did you tried with GLPI 9.5 ? We recently fixed an issue that was causing an infinite loop when using a calendar that has no opening days.

Regards

[paulopera]

Hi @cedric-anne , thanks for the update and yes the fix solved the main problem. Now when I set a SLA it doesn't trigger the loop!
Do you recommend that I open a new issue for the other issue I reported?
Thank you so much for all the help!

[cedric-anne]

Hi @cedric-anne , thanks for the update and yes the fix solved the main problem. Now when I set a SLA it doesn't trigger the loop!
Do you recommend that I open a new issue for the other issue I reported?
Thank you so much for all the help!

Yes, you should open another issue, and describe all steps to reproduce.

Regards

[paulopera]

As mentioned by @cedric-anne the issue was solved with the update 9.5.1.

[paulopera]

@cedric-anne I'm so sorry! The loop still persists if the ticket SOLVED and I try to set a SLA to the ticket.
When I answered and closed the issue an hour ago I did the test with an open ticket and not with a solved one which was the main problem with this action.
The mysql.log displays the same as in the OP: