Description of problem: this bug is connected with https://bugzilla.redhat.com/show_bug.cgi?id=725726 comment #12 there I try to get testcases of run and it causes only: XML-RPC fault: DoesNotExist: User matching query does not exist. but in case there is lots of testcases, and some of testcases contains something wrong, in this case propably some unicode chars, I'm not able to find which of them is wrong to repair it. Similar also for user, there should be output with more details. There should be more explanative output when any traceback in XML-RPC interface for example: in testcaserun when getting testcases there should be testcaseid what is wrong. In user query there should be also user id which contain wrong chars Regards Honza
I've found problematic TestPlan: 4333. It is unable to show cases (propably one of cases is malformed or contains some bad char and this causes that cases are not shown: #!/usr/bin/python import re, sys, ast sys.path.append("/usr/share/qa-tools/") sys.path.append("/usr/bin/") import Nitrate tc=Nitrate.TestPlan(4333) print tc for testcase in tc: print "> " print testcase ======================= $ DEBUG=2 ./test.py [DEBUG] Caching on level 2 [DEBUG] Coloring enabled [INFO] Fetching test plan TP#4333 [INFO] Contacting server https://tcms.engineering.redhat.com/xmlrpc/ [DEBUG] Initializing test plan TP#4333 [DEBUG] {'attachment': [], 'author': 'jscotka', 'author_id': 2150, 'case': [13639, 13640, 13641, 46253, 13642, 65794, 13643, 13644, 13645, 65795, 13646, 46254, 13647, 13648, 13649, 13650, 13651, 46255, 13652, 46262, 11649, 46256, 46257, 46258, 56950, 56951, 81093, 68645, 111951, 111952, 111956, 111217, 13653, 13654, 98162, 13655, 13656, 13657, 13658, 13659, 13660, 13664, 13665, 13661, 13662, 13663, 46263, 65796, 13637, 13638, 51551, 46259, 65755, 65747, 65756, 94919, 46260, 46261, 115426, 45702, 69095, 69916, 11647, 57965, 56953, 57963, 57962, 57966, 14915, 14918, 11673, 11648, 11650, 11651, 11653, 11652, 11659, 11658, 11655, 11657, 11656, 11672, 11671, 11654], 'component': [], 'create_date': '2011-07-28 00:35:14', 'default_product_version': '2.3.1', 'env_group': [], 'extra_link': None, 'is_active': True, 'name': 'cups / General', 'owner': 'None', 'owner_id': None, 'parent': 'BaseOS / Components / Daemons', 'parent_id': 3784, 'plan_id': 4333, 'product': 'Dummy Product', 'product_id': 66, 'tag': [], 'type': 'General', 'type_id': 26} [DEBUG] Caching user UID#2150 TP#4333 - cups / General [INFO] Fetching TP#4333's cases Traceback (most recent call last): File "./test.py", line 9, in <module> for testcase in tc: File "/usr/share/qa-tools/Nitrate.py", line 1864, in __iter__ for testcase in self.testcases: File "/usr/share/qa-tools/Nitrate.py", line 1385, in __iter__ for item in self._items: File "/usr/share/qa-tools/Nitrate.py", line 1368, in _items self._get() File "/usr/share/qa-tools/Nitrate.py", line 2584, in _get self._server.TestPlan.get_test_cases(self.id)]) File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/usr/share/qa-tools/nitrate.py", line 120, in request_with_cookies return self._parse_response(h.getfile(), sock) File "/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response return u.close() File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: <Fault 1: 'DoesNotExist: User matching query does not exist.'>
Generally, exceptions encountered while interacting with server will result in a short line of exception information in local xmlrpclib, such as the one logged above, normally, it would be explanative enough to understand what's going on. Exceptionally, there are cases, such as the one above where retrieving a testcase will get an exception says 'User matching query does not exist', this is caused by a programming error, and it was fixed already. Exceptions are different from errors. For errors, we are able to provide more explanative information programably, while for exceptions(it would be difficult to anticipate a specific exception type among so many XMLRPC calls in which case the proper humanization is possible), there are only original traceback information that is automatically formatted by xmlrpc serialzier.
the programming error is fixed. and the exception info is not belong to the programming.