Consistent XML and JSON RPC error codes

[Olemis Lang]

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 .

[osimons]

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

• The use of error code 1 as general error likely goes back to the first implementation, based on the Wiki RPC specification: ​http://www.ecyrd.com/JSPWiki/wiki/WikiRPCInterface2

• 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:

6. 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.

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

[Olemis Lang]

Replying to osimons:

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 .

• The use of error code 1 as general error likely goes back to the first implementation, based on the Wiki RPC specification: ​http://www.ecyrd.com/JSPWiki/wiki/WikiRPCInterface2

[...]

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 ;)

[Olemis Lang]

Replying to olemis:

Replying to osimons:

[...]

• The use of error code 1 as general error likely goes back to the first implementation, based on the Wiki RPC specification: ​http://www.ecyrd.com/JSPWiki/wiki/WikiRPCInterface2

[...]

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.

[...]

[osimons]

Replying to olemis:

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.