action #15192

[tools]DB exception popup while trying to add Test Suite with same name

Added by asmorodskyi about 3 years ago. Updated 9 months ago.

Status:ResolvedStart date:01/12/2016
Priority:LowDue date:
Assignee:mkittler% Done:

0%

Category:Feature requests
Target version:Done
Difficulty:
Duration:

Description

observation

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 )

suggestion

UI should block this attempt by :
1. disable Test Suites that already added
2. filter out Test Suites which already added from the list

workaround

Don't add same test cases

Screenshot_20161201_132224.png (135 KB) asmorodskyi, 01/12/2016 12:51 pm

2688

Related issues

Related to openQA Project - action #14964: openQA WebUI - Join Medium to Group got error message Rejected 23/11/2016
Related to openQA Project - action #57143: [YAML] Editor does not check if same combination of test ... Resolved 20/09/2019
Duplicated by openQA Project - action #17600: Adding same scenario in multiple job groups fails Closed 08/03/2017

History

#1 Updated by mkittler about 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.

#3 Updated by okurz about 3 years ago

  • Related to action #14964: openQA WebUI - Join Medium to Group got error message added

#4 Updated by okurz about 3 years ago

  • Category set to Feature requests

#5 Updated by RBrownSUSE almost 3 years ago

  • Subject changed from DB exception popup while trying to add Test Suite with same name to [tools]DB exception popup while trying to add Test Suite with same name

#6 Updated by mkittler almost 3 years ago

  • Status changed from New to In Progress

#7 Updated by coolo almost 3 years ago

I would recommend to add some basic tests to this route - as it's so seldomly used we discover regressions only late otherwise

#9 Updated by okurz over 2 years ago

Apparently https://github.com/os-autoinst/openQA/pull/1318 broke something.

observation

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

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 over 2 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 (Tests and x86_64).

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 over 2 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.

#12 Updated by mkittler over 2 years ago

  • Status changed from In Progress to Feedback

#13 Updated by coolo over 2 years ago

  • Duplicated by action #17600: Adding same scenario in multiple job groups fails added

#14 Updated by mkittler almost 2 years ago

  • Assignee deleted (mkittler)

#15 Updated by szarate 9 months ago

  • Status changed from Feedback to Resolved
  • Assignee set to mkittler
  • Target version set to Done

This is donce since a while ago :)

#16 Updated by mkittler 9 months ago

Note that in my previous comment I confused this with the exception you still get when adding a new test suite with a name which already exists. But according to the screenshot this is actually about job templates and yes - I fixed it a while ago.

#17 Updated by mkittler 5 months ago

  • Related to action #57143: [YAML] Editor does not check if same combination of test suite/arch/flavor/version already used in different job group added

Also available in: Atom PDF