New middleware to catch any OptimadeWarnings
#431
Conversation
This is put as the first added middleware, since the order in which middleware is added to the application matters. See https://www.starlette.io/middleware/ The middleware is a bit hacky, since it's based on Starlette's `BaseHTTPMiddleware`, which uses the `call_next` function that creates a `StreamingResponse`. This middleware will temporarily stitch the response back together, add the warnings, and chop up the response again, returning a new StreamingResponse.
Codecov Report
@@ Coverage Diff @@
## master #431 +/- ##
==========================================
- Coverage 91.09% 90.95% -0.14%
==========================================
Files 55 56 +1
Lines 2548 2632 +84
==========================================
+ Hits 2321 2394 +73
- Misses 227 238 +11
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Warning needs the message to be a string, not None.
Test "regular" warnings are still handled fine
It seemed the places I could find to add warnings to didn't need it. Instead there are now two new Warning classes, which didn't need using, but may still be usable in other situations.
|
I couldn't find more places to add warnings. Actually, I couldn't find any. So please feel free to add them where you think they're needed. |
|
By the way, the codecov diff is bad due to mainly no warnings being used in the servers so far. Hence, I cannot test for them to exist. But as soon as we can introduce a warning somewhere, this will be properly tested as well. It seems a bit backward, but oh well, I couldn't come up with a good way of testing this in situ otherwise. |
This is put as the first added middleware, since the order in which middleware is added to the application matters.
See https://www.starlette.io/middleware/
The middleware is a bit hacky, since it's based on Starlette's
BaseHTTPMiddleware, which uses thecall_nextfunction that creates aStreamingResponse.This middleware will temporarily stitch the response back together, add the warnings, and chop up the response again, returning a new
StreamingResponse.Another thing that's a bit hacky about this is the way in which warnings are collected. I currently use an in-memory attribute from the middleware class, however, I am not sure if this is thread-safe.
Note, I have tested this by raising a simple warning in a router and it seemed to work :)
Closes #105
Missing: