Unexpected error response about bioblend

[jmchilton]

So ideally all API exceptions would get handled through this method - they don't and that is a problem (https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/web/framework/decorators.py#L280). That said - we could build better exceptions on this side of things I think to handle the good and bad Galaxy exceptions:

GalaxyExceptionGeneric(Exception):
    """Generic non-2XX response exception with r.text and status_code available"""
    ...

GalaxyException(GalaxyExceptionGeneric):
    """properly formatted exception with extra fields for err_code, err_msg, extra_error_info, traceback (for admins)"""
    ...

[nsoranzo]

I'm not comfortable with just raising r.text, but the GalaxyException approach would be nice!

[hexylena]

@jmchilton the error message IS coming from the correct API decorator on the galaxy side. On the BioBlend side, it's being handled differently in some weird cases:

After more digging, this appears to be the norm, with

bioblend.galaxy.client.ConnectionError: Unexpected response from galaxy: 400: {"traceback": "Traceback (most recent call last):\n  File \"/home/users/cpt/cpt/esr/Projects/galaxy/galaxy/lib/galaxy/web/framework/decorators.py\", line 251, in decorator\n    rval = func( self, trans, *args, **kwargs)\n  File \"/home/users/cpt/cpt/esr/Projects/galaxy/galaxy/lib/galaxy/webapps/tool_shed/api/repositories.py\", line 628, in create\n    raise exceptions.RequestParameterInvalidException( invalid_message )\nRequestParameterInvalidException: You already own a repository named <b>test<\/b>, please choose a different name.\n", "err_msg": "You already own a repository named <b>test<\/b>, please choose a different name.", "err_code": 400008}

Looking further, I'm getting bioblend.galaxy.client.ConnectionErrors for just about all of my exceptions. That said, I used this sort of parsing in planemo and that behaves nicely and prints err_msg rather than the JSON string.

I think I'm starting to see it...make_post_request is the ONLY method to use a ConnectionError? The rest of the methods don't catch the exceptions at all, and toss the upwards as-is.