-
-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[16.0][fix] fastapi: init inner_exception properly #488
Conversation
It looks to me that if the app does not yield anything for the response you might encour into an attribute error as the attribut won't be defined yet. In general, the init method sounds like a better place for shared attributes. Fixes OCA#487
Hi @lmignon, |
@@ -47,7 +52,6 @@ def handle_error(self, exc): | |||
def _make_response(self, status_mapping, headers_tuple, content): | |||
self.status = status_mapping[:3] | |||
self.headers = dict(headers_tuple) | |||
self.inner_exception = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO you still need to reset the inner_exception each time you process a new response
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lmignon my understanding, but correct me if I'm wrong, is that the dispatcher will be re-initialized for each request. Now, if the assumption of the re-init per request is correct I wouldn't bother handling this differently.
Another point: even assuming you are correct, if you reset it for each iteration you might lose a previous exception. Hence, we should probably do a check if it is valued already and do not override it.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simahawk I think I was wrong 😏
It would be nice to have a test reproducing this error... |
This PR has the |
/ocabot merge nobump |
This PR looks fantastic, let's merge it! |
@lmignon your merge command was aborted due to failed check(s), which you can inspect on this commit of 16.0-ocabot-merge-pr-488-by-lmignon-bump-nobump. After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red. |
/ocabot merge patch |
Hey, thanks for contributing! Proceeding to merge this for you. |
Congratulations, your PR was merged at b8dd3a4. Thanks a lot for contributing to OCA. ❤️ |
It looks to me that if the app does not yield anything for the response you might encour into an attribute error as the attribute won't be defined yet.
In general, the init method sounds like a better place for shared attributes.
Fixes #487