| << Back to previous view |
|
[QB-2704] QB throw exceptions when deleting a configuration.
|
|
| Status: | Resolved |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 6.1.11 |
| Fix Version/s: | 6.1.15 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Phong Trinh | Assigned To: | Robin Shen |
| Resolution: | Fixed | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Environment: | QB Server on Linux Machine | ||
| File Attachments: |
QB - Unable to delete a Configuration.txt
|
| Description |
|
QB threw exceptions every time I delete a configuration. The exceptions are as in the attached file. This issue is critical, please look into it as soon as possible.
Thank you, ptrinh |
| Comments |
| Comment by Robin Shen [ 28/Apr/16 12:31 AM ] |
|
The configuration with id "4233" is no longer exists, Can you please restart QB server and try again, if this problem still exists, there is a possibility that your database records is in inconsistent state, and it can be caused by two reasons:
1. you are using the embedded database which is not assumed for production use. 2. you are using MySQL with MyISAM storage engine, which can not ganrantee foreign key integreity |
| Comment by Phong Trinh [ 28/Apr/16 02:40 PM ] |
|
Thank you for promptly response.
We are not using embedded database nor MySQL for my QB server. We am using Postgres database. I am still unable delete any QB configuration after the QB server was restarted. Looks like it is a QB bug. |
| Comment by Phong Trinh [ 28/Apr/16 03:54 PM ] |
|
One of my colleagues found out root cause of the issue. When we deleted a configuration in my case 4233, QB deleted the configuration, but didn't cancel its builds which were in the queue. The builds were in the queue forever. So when we tried to delete another configuration, QB still looked for configuration 4233. It was no longer exist, and QB throw the exceptions. What we needed to do was to cancel the builds in the queue which were associated to the configuration 4233.
I think when QB deletes a configuration, it should delete all of the builds associate to the configuration in the queue. Or QB prompts user to cancel the builds prior to deleting the configuration. |
| Comment by Robin Shen [ 29/Apr/16 12:44 AM ] |
| Yes we should warn user to stop builds before deleting a configuration. However even if this happens, I can not reproduce the issue of not being able to delete other configurations afterwards. Would you please do some more tests and come with some reproducing steps, including information such as relationship between the configuration being deleted afterwards and configuration 4233, etc. |
| Comment by Phong Trinh [ 29/Apr/16 02:48 PM ] |
|
The steps are as the follows:
1) Schedule a QB configuration for example, Configuration_A to run. 2) Pause the system or make its build to wait for a node, so the build is queued. 3) Delete Configuration_A, QB will not warn that its build is still in queue. 4) Check to see the build is still in the queue after the deletion. I am sure it is. 5) Try to delete another Configuration for example, Configuration_B. QB will throw an exception that the Configuration_A is no longer exist. Indeed, Configuration_A was deleted, but its build is still hanging in the queue. Since QB throws the exception/crashed, the Configuration_B can not be deleted. |
| Comment by Robin Shen [ 30/Apr/16 01:28 AM ] |
| Sorry I was wrong previously (testing on an old branch), actually QB does not allow you to delete a configuration when there are running/waiting build in queue. This also holds true for 6.1.11. Can you please verify it again? |
| Comment by Phong Trinh [ 05/May/16 10:25 PM ] |
| I am able to reproduce the issue here. QB does not allow you to delete a configuration via UI when there are running/waiting build in queue, but it allows you delete it using RESTFul. Please try the scenario, but use REST to delete the configuration in step 3. |
| Comment by Robin Shen [ 06/May/16 12:43 AM ] |
| Thanks this is indeed the case, will get it fixed in next patch release. |
| Comment by Phong Trinh [ 06/May/16 02:15 PM ] |
| Thank you. |