Connexion: Resolver eating exceptions

[writeson]

Description

The Resolver method resolve_function_from_operation_id() has an ending except AttributeError: This exception handler raises the previously created msg string. The problem is it eats any other exceptions that are raised in the process of resolving the endpoint. So for example, if code is being imported to as the endpoint is resolved, and that code raises an exception, the exception will be misleading. The user will think it's a error in their swagger file.

Expected behaviour

Actual behaviour

Steps to reproduce

Additional info:

Output of the commands:

• python --version
• pip show connexion | grep "^Version\:"

[mvalkon]

@writeson thanks for raising an issue. Could you provide a more thorough example where this happens, so we could think about how to fix it?

I quickly checked the function you mentioned and sure, it will catch ImportError, AttributeError and ValueError. But it certainly won't catch _all_ exceptions.

[writeson]

Mikko,

Thanks for getting back to me, much appreciated. I can tell you the
specific error as it was pretty simple really. The problem was (couple of
times now) that while modifying my REST endpoint code, I introduced bugs
that would cause the code to fail when imported, raising an AttributeError.
This is fine, an expected behavior. The problem is the Resolver catches
the AttributeError and raises it's own with it's own message about "unable
to resolve....". This completely hides the traceback of the code that
generated the AttributeError, making it much more difficult to fix it.

Because the 'except AttributeError:' in the Resolver doesn't do something
like this 'except AttributeError as e:', putting a breakpoint in the
exception handler doesn't help. And I ran into a situation in production
where a small configuration file change caused the AttributeError, but I
couldn't debug it and we bounced around trying to fix the problem through
inspection.

I 'fixed' the problem by deriving my own Resolver class (which I've
attached to this email). It essentially just logs the source exception
before the raise of the ResolveError(msg)

Hope this is helpful, and again, thanks for getting back to me. The
Connexion module is fantastic!!

Doug

On Thu, Oct 5, 2017 at 3:33 AM, Mikko Valkonen [e-mail]
wrote:

@writeson https://github.com/writeson thanks for raising an issue.
Could you provide a more thorough example where this happens, so we could
think about how to fix it?

I quickly checked the function you mentioned and sure, it will catch ImportError,
AttributeError and ValueError. But it certainly won't catch all
exceptions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zalando/connexion/issues/518#issuecomment-334382743,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARsHaP2-mCoV03mQp91CK5PCRUY3bMtks5spIY6gaJpZM4PkzyF
.

[mvalkon]

@writeson thanks for the explanation. Unfortunately the custom Resolver-class did not end up in the github issue, but that's not a problem.

Could you check which version you're currently running? I should've checked earlier but this problem was reported before in #377 and then fixed in #411. Later fixes introduce a slightly better formatting. The current function looks like this, I think it should be informative enough to not mask any of the caught exceptions.

[writeson]

Mikko,

Yeah, I only attached my derived Resolver class to the email, didn't put it
into GitHub as I wanted to answer your question before going any further.

Because of various reasons in our server environment, we are running
Connexion version 1.1.10.1 with Python 2.75. So that could well be part of
the problem, we don't have the fix in the version we're running. Looking at
the current version of the Resolver (thank you for the link), that looks
like a very good solution.

Thanks for the follow-up!
Doug

On Thu, Oct 5, 2017 at 3:52 PM, Mikko Valkonen [e-mail]
wrote:

@writeson https://github.com/writeson thanks for the explanation.
Unfortunately the custom Resolver-class did not end up in the github
issue, but that's not a problem.

Could you check which version you're currently running? I should've
checked earlier but this problem was reported before in #377
https://github.com/zalando/connexion/issues/377 and then fixed in #411
https://github.com/zalando/connexion/pull/411. Later fixes introduce a
slightly better formatting. The current function looks like this
https://github.com/zalando/connexion/blob/d8019b346e1646be8216ffe4fc2172d28cce5185/connexion/resolver.py#L64,
I think it should be informative enough to not mask any of the caught
exceptions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zalando/connexion/issues/518#issuecomment-334573713,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARsHeerAqCJgm2ZCi_i4qBiZe3GMbtFks5spTN_gaJpZM4PkzyF
.