Opened 3 years ago

Consistent XML and JSON RPC error codes

Reported by: Owned by: olemis osimons normal XmlRpcPlugin normal error codes

Description

Handling of (XML|JSON)-RPC error codes does not seem to be consistent. Everything is explained in this ticket . IMHO both protocols should be returning the same error codes , but I do not know whether this will cause any trouble regarding interoperability with external tools e.g. Mylyn .

comment:1 follow-up: ↓ 2 Changed 3 years ago by osimons

There are indeed differences, both due to history and (low) level of effort put in place to ensure we capture the right problem.

• In the RPC code all we really do is find the method and call it with the arguments we have. The code can fail for all kinds of reasons, and we have no layer in place to ensure that these are filtered correctly. It can be wrong number of arguments, and it can be wrong types or incorrect order. How far should we go in detecting all options? More than TypeError?
• With the added complexity of some inputs being 'composite' inputs (like ticket attributes) it can be argued that input can still look correct but still be technically wrong. I think the code generally raises TracError. This should be discouraged, and data input errors should instead raise ValueError.

So, based on your proposed changes:

1. Yes, no problem making -32603 the general error instead of 1, but do note the special case of the wiki which then should raise a wiki-local custom error 1 instead. We would then need a ServiceCustomException that handlers can use for making custom errors that should pass through as-is with error codes and all. This will let methods adhere to custom data/error specifications.
1. Best bet for catching most -32602 errors would likely be catching TypeError and ValueError. No guarantees, but hopefully more right than wrong - and better than current situation of problems just getting caught up in ServiceException.

Patch welcome...

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 3 years ago by olemis

There are indeed differences, both due to history and (low) level of effort put in place to ensure we capture the right problem.

I think a simple approach would be to map exception types to error codes .

[...]

AFAICS , it is reserved for No such page was found., so I guess it'd be possible to map all instances of ResourceError to XML-RPC error code 1 ?

Patch welcome...

/me working on it ;)

comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 3 years ago by olemis

[...]

[...]

AFAICS , it is reserved for No such page was found., so I guess it'd be possible to map all instances of ResourceError to XML-RPC error code 1 ?

BTW , right now this is what happens

>>> from xmlrpclib import ServerProxy as SP
>>> p = SP('http://127.0.0.1:8082/env/rpc')
>>> p.wiki.getPage('LQQD')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/xmlrpclib.py", line 1199, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.6/xmlrpclib.py", line 1489, in __request
verbose=self.__verbose
File "/usr/lib/python2.6/xmlrpclib.py", line 1253, in request
return self._parse_response(h.getfile(), sock)
File "/usr/lib/python2.6/xmlrpclib.py", line 1392, in _parse_response
return u.close()
File "/usr/lib/python2.6/xmlrpclib.py", line 838, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 404: 'Wiki page "LQQD" does not exist'>


So it seems to me that returned error code is 404 ? Should it be 1 ?

That seems to be the behavior by design , see test_resource_not_found test case.

[...]

comment:4 in reply to: ↑ 3 Changed 3 years ago by osimons

xmlrpclib.Fault: <Fault 404: 'Wiki page "LQQD" does not exist'>

So it seems to me that returned error code is 404 ? Should it be 1 ?

Hmm. Didn't think we needed to sacrifice the 404 error, but that really depends on how strongly we want to adhere to the WikiRPC spec. No one has cared about this for all these years, and it is not like the WikiRPC spec is on everyones lips anymore... I say we just leave it as it is.