Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

Closed Test Plan does not appear as completed in Milestone


We are just starting to use TestRail in our production environment and I’ve started to close test plans and complete milestones. One of the closed test plans is in a strange state where it is closed so I can no longer edit the test plan, however it has not moved to Completed in the Milestone. It also appears in the list of Active test plans which is most annoying.

I don’t see anything useful in the system logs but they are being flooded by this issue.

I’ve tried completing/uncompleting the milestone but that has no effect. I can’t delete the test plan since it is closed. I don’t really see anything else I can do to get this plan in to a good state.

Any help would be appreciated.


Hi Bruce,

Thanks for your posting. It looks like there was an issue with closing the test plan or parts of the test plan (e.g. a database issue in the middle of the transaction). You can simply close the plan again and TestRail will finish closing the test plan in this case. Can you try this please?



I’m not able to edit this test plan so I can’t really attempt to close it again.


Oh…I see there is a lock icon which I can use to attempt to close the plan again.

After a bit if delay that seemed to kick it into the correct state.



Hi Bruce,

Yep, via the lock icon and good to hear that it everything looks okay now :slight_smile:



We just finished our second set of milestones and again the test plans refuse to close. This time I have been unable to close any plans regardless of how many times I press the lock button.

Here is one of the error messages in the log.


11:25:48	[DeadlockException] Lock wait timeout exceeded; try restarting transaction

File: /opt/testrail-
Line: 25
Status Code: 500
Uri: /index.php?/plans/close/1371 (POST)

Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
PHP: 5.5.9-1ubuntu4.16
Server: Linux 4.2.0-35-generic #40~14.04.1-Ubuntu SMP Fri Mar 18 16:37:35 UTC 2016 x86_64

_token: OOOwY0622xG9pnrBZqmo

at ex::raise (mysql.php:167)
at Database_mysql_driver->_throw_last_error (mysql.php:106)
at Database_mysql_driver->execute (database.php:925)
at Database_library->query (suite.php:283)
at Suite_model->lock (suite.php:1319)
at Suite_model->_trx_archive (:)
at call_user_func_array (callback.php:70)
at callback::runv (database.php:1212)
at Database_library->_transaction_run (database.php:1178)
at Database_library->transaction_run (suite.php:1314)
at Suite_model->archive (run.php:1706)
at Run_model->_close (run.php:1801)
at Run_model->_trx_cascading_close (:)
at call_user_func_array (callback.php:70)
at callback::runv (database.php:1235)
at Database_library->_transaction_exec (database.php:1221)
at Database_library->_transaction_run (database.php:1178)
at Database_library->transaction_run (run.php:1792)
at Run_model->_cascading_close_for_plan (run.php:1751)
at Run_model->close_plan (plans.php:681)
at Plans_controller->close (:)
at call_user_func_array (controller.php:257)
at Controller->_invoke_web_call (controller.php:168)
at Controller->_invoke_web (controller.php:120)
at Controller->_invoke (gizmo.php:107)
at require_once (index.php:106)

11:25:48 Database error code: 1205 (at Database_mysql_driver->_throw_last_error)
11:25:48 Query took 51436.79 ms (at Database_driver->_after_query)
– suites_lock
id = 2
FOR UPDATE (at Database_driver->_after_query)


Hi Bruce,

Thanks for the update. Deadlock and lock timeout issues usually indicate a performance issue on the database side and you can see that queries take a long time with your database (“Query took 51436.79 ms”). Can you check the database performance and load on the machine? Is this a virtual machine? Are there other applications running that use the same database server?



Thanks Tobias. We’ll look at the database configuration. The database is shared with other applications which all appear to be running fine.

Is the timeout something configurable within the TestRail application? Is this something we could increase so we can close test plans while we root cause the problem?



Hi Bruce,

Yes, this is configurable but on the MySQL database level and this is independent of TestRail:

I would also recommend reviewing the performance/load of the database and I’m happy to help in case you have any questions.