-
Notifications
You must be signed in to change notification settings - Fork 44
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
Added convenience variables for middleware and exception handlers #537
Conversation
Codecov Report
@@ Coverage Diff @@
## master #537 +/- ##
==========================================
- Coverage 91.51% 91.47% -0.04%
==========================================
Files 62 62
Lines 3123 3110 -13
==========================================
- Hits 2858 2845 -13
Misses 265 265
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
Seems good.
As you point out yourself, we might want to do this for the the exceptions handlers as well, however, this does not seem as straight forward since you need to match the handlers up with Exception
s. But if you have a good idea in mind, I don't mind merging this PR with two distinct commits for each of these (middleware + exception handlers).
Also, do you think REQUIRED_MIDDLEWARE
is the best name? Specifically thinking about the REQUIRED
part. Maybe just OPTIMADE_MIDDLEWARE
?
I have accepted this PR though, since I have no strong opposing opinion on the above points, and am fine with it as is. However, a comment on each point would be good before merging.
f020cbe
to
f9dbb4a
Compare
Done, didn't seem so bad. Side effect is that the index server will also handle
I agree that's clearer, so updated it.
I also added docstrings and typehints to the new constants, which mkdocstrings handles quite nicely (note the docs for the |
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.
Nice with the doc strings!
The CORS middleware should be added before our custom middleware due to AddWarnings
needing to be last.
It's a bit worrying the tests are not catching this, maybe it was too difficult setting one up properly? But this is what I remember from creating the middleware, and what I also put into its doc string.
Where does it say this in the docs? Struggling to find it. Might be worth adding a note in the docstring of |
Yeah, just read it through. What I remembered was this, but that obviously has nothing to do with when to add it to the application. |
Cool, feel free to add it to this PR where/when you please (there's no rush to get this in) |
77fd124
to
a23083c
Compare
Done. |
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.
Fine for me now.
As stated above, if you wish to distribute the text I added in other places, feel free, I will re-review later then :)
d8ce7cb
to
1a617d3
Compare
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.
Looks great now. I've again approved, since my suggested change is not crucial, I just thought it might make the note look more accessible by having a "one line summary".
I'll just quickly rebase this into 2 commits; one for middleware by both of us and one for exception handlers by me |
…exception handlers
3ac9446
to
a19d996
Compare
Done, so much for a short and sweet PR! |
- Updated docstrings to clarify importance of middleware ordering, in particular that AddWarnings must come first/last. Co-authored-by: Casper Welzel Andersen <[email protected]>
a19d996
to
7310237
Compare
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.
Cheers @ml-evs !
Closes #536.