Modify

Opened 12 months ago

Last modified 12 months ago

#11311 new enhancement

Consistent XML and JSON RPC error codes

Reported by: olemis Owned by: osimons
Priority: normal Component: XmlRpcPlugin
Severity: normal Keywords: error codes
Cc: Trac Release:

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 .

Attachments (0)

Change History (4)

comment:1 follow-up: Changed 12 months 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: Changed 12 months ago by olemis

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 .

[...]

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: Changed 12 months ago by olemis

Replying to olemis:

Replying to osimons:

[...]

[...]

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 12 months ago by 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.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.