[tools]DB exception popup while trying to add Test Suite with same name
you will get DB exception ( see attached screenshot )
steps to reproduce¶
- Try to add same Test Suite to Job Group second type
- you will get DB exception ( see attached screenshot )
UI should block this attempt by :
1. disable Test Suites that already added
2. filter out Test Suites which already added from the list
Don't add same test cases
#1 Updated by mkittler over 3 years ago
- Assignee set to mkittler
- Priority changed from Normal to Low
I'm aware of this. I didn't put any effort in it as I didn't find this very important (there is an error message, just not a very good one). There are some other places in openQA where constraints are not checked before, too.
#9 Updated by okurz almost 3 years ago
Apparently https://github.com/os-autoinst/openQA/pull/1318 broke something.
Trying to add zdup_13.2_cryptlvm@uefi in Jobs for openSUSE Leap 42.3 in opensuse-42.3-DVD on https://openqa.opensuse.org/admin/job_templates/28 fails with "wrong parameter: machine_id". Checking the POST request I can see that the parameter is not set at all. It looks like this is caused by "filterTestSelection" within job_templates.js being called on the current index but the problem could so far be reproduced only for this specific value. I could reproduce the problem also based on the database dump from 2017-05-28 on my machine
steps to reproduce¶
- go to https://openqa.opensuse.org/admin/job_templates/28
- try to add "uefi" to zdup_13.2_cryptlvm on the DVD group
- observe the error
To reproduce locally use database dump from o3.
It seems the PR adding tests https://github.com/os-autoinst/openQA/pull/1327 is not testing the part about trying to define an actual scenario on the second test selection. It only looks for test suites selections and also this part might miss the fact that actually the same test suite can be added twice - which it probably shouldn't.
https://github.com/os-autoinst/openQA/pull/1349 created to temporarily revert.
#10 Updated by mkittler almost 3 years ago
I created another PR which fixes the issue mentioned in the previous comment by @okurz. It simply occurred because
uefi is in both columns (
But as discussed with @okurz the issue isn't solved yet because the current approach doesn't handle the case where product_id machine_id and test_suite_id are identical but the job group differs. I suppose in this case it is not a good idea to just remove the conflicting entries from the selection. Otherwise the user would wonder why entries are missing. It is not obvious why the entries are missing because the conflicting templates are on a different job template page in this case. Instead the error message should tell the user on which job template page the conflicting template is. By the way, does it even make sense that group_id is not part of the unique constraint?
#11 Updated by mkittler almost 3 years ago
In order to distinguish the unique constraint error from other database errors the error handling in line https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI/Controller/API/V1/JobTemplate.pm#L111 must be improved. However, I'm currently unable to do it. I discovered the following options, but I'm not sure how to continue:
- In other places we're using try-catch via Try::Tiny but it only provides an error string, too. The fact that the error string is even localized does not make parsing easier.
- There is DBIx::Error but it is not packaged yet. It also seems a bit unreasonable to add an extra dependency for this.
- It seems to be possible to register a custom error handler, but that's connection-wide and hence not convenient to use and might break other places.
- As a workaround just check the constraint violation manually.