Log traceback errors on model

[aschn]

Fixed issue #16

This adds an errors field, and sets it by overwriting the handle_exception method on the view mixin. The response body is unaffected.

[coveralls]

Changes Unknown when pulling be1fe2b on handle_500 into * on master*.

[triat]

Hey, thanks for the fix. Is it going to be merged soon ?

[avelis]

@triat It most certainly can. I believe @aschn wanted to be sure this PR actually worked for issue #16 before merging. If it does then I can merge it in. However, that was certainly a long time ago.

[triat]

Sure I just wanted to know because we had the error yesterday with a malformation of a JSON causing a 500.

[triat]

@avelis Can I help you on this one ? as we got the errors too.

[avelis]

@triat By all means. All contributions are appreciated.

[triat]

Hey @avelis, I took the branch on local and tried to pass the tests and they are working on my machine. Could it be possible to rebase the branch from master ? Thanks

edit: ok nvm, I've reproduce the errors (finally got a working tox installation)

[triat]

Hey @avelis, do you need an other PR to fix the conflicts or you can do it ? Thanks

[avelis]

@triat probably need a PR to fix this. Been really tied up at work as of late

[triat]

Sure, no problem @avelis. I just created a new PR as I can't fix the conflict here. Hope it helps you. Thanks for your reactivity

[coveralls]

Coverage increased (+0.003%) to 40.768% when pulling b27bc96 on handle_500 into d4cf08f on master.

[coveralls]

Coverage increased (+0.003%) to 40.768% when pulling b27bc96 on handle_500 into d4cf08f on master.

[coveralls]

Coverage increased (+0.003%) to 40.768% when pulling b27bc96 on handle_500 into d4cf08f on master.

[triat]

About those tests, I don't know if we should have a look or if it's normal that they are slow sometimes ?

[avelis]

@triat There is a couple of things we could do. We could simply re-teach to the test to the new time. 42 ms I believe. We could also use flaky but I doubt that will lower the time for those scenario's. Thoughts?

[triat]

@avelis I'm not a huge fan of changing the limit time, if your goal is to have an API with a response time with max 200 ms, having drf-tracking take already almost 25% of your response time.

Something that we could do to reduce this amount to 0 is to start using the async in python 3 and / or try to do something similar for python 2 (config with celery?)

[avelis]

@triat Not against Python 3 async but am concerned with Python 2 and Celery. I like Celery to be honest but am concerned forcing people to use that technology to reduce the middleware's overhead.

[triat]

@avelis I'm not talking about forcing them put maybe propose a configuration working with celery if people really do care about their API response time.
The other solution in Python 2 multithreading but from what I heard, it's far from being simple to use

[triat]

@avelis Hey, can we check now if the tests pass here too by rebasing on master? Thanks

[avelis]

@triat I was able to do merge via the Github Desktop UI. We can now observe if the checks pass.

[coveralls]

Coverage increased (+0.03%) to 40.882% when pulling 597585a on handle_500 into b767aa0 on master.

[coveralls]

Coverage increased (+0.03%) to 40.882% when pulling 597585a on handle_500 into b767aa0 on master.

[coveralls]

Coverage increased (+0.03%) to 40.882% when pulling 597585a on handle_500 into b767aa0 on master.

[coveralls]

Coverage increased (+0.03%) to 40.882% when pulling 597585a on handle_500 into b767aa0 on master.

[triat]

@avelis apparently it does 👍

[triat]

Hey @avelis, can I just ask you, when you have time, to trigger the build for pipy :) thanks a lot