-
Notifications
You must be signed in to change notification settings - Fork 2
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
Log refactoring #39
base: master
Are you sure you want to change the base?
Log refactoring #39
Conversation
Codecov Report
@@ Coverage Diff @@
## master #39 +/- ##
==========================================
+ Coverage 57.78% 59.47% +1.69%
==========================================
Files 33 33
Lines 4157 4163 +6
==========================================
+ Hits 2402 2476 +74
+ Misses 1755 1687 -68
Continue to review full report at Codecov.
|
@volodymyrss Remember if this TODO was discussed at some point in time? dispatcher-app/cdci_data_analysis/flask_app/dispatcher_query.py Lines 134 to 138 in 37a0eb8
I think some log might still be useful, but perhaps without the scratch_dir |
This pull request introduces 2 alerts when merging 37a0eb8 into 2f47456 - view on LGTM.com new alerts:
|
I think it would be still good to store log in the individual scratch directory of the job. It allows to inspect the job for each request easily near data. In some cases it is still useful. |
tests/test_server_basic.py
Outdated
jdata=c.json() | ||
|
||
assert c.status_code == 200 | ||
|
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.
can we add a test to check if log was created? because the problem was that it was not, that's why it was commented, I think
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.
It was crashing mainly because the job_id was not set for that specific case, and when trying to create the folder it would not find that job_id.
I will add the check
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.
and also that it does not create a new logger for each request. That's what was happening at some points too.
I find it is convenient to inspect loggers with logging_tree, but simply logging would do too.
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.
I am trying to use logging_tree to inspect the log, but I am struggling a bt, what do you think of verifying that the log file is actually created? Will this be enugh for us?
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.
it will be necessary but not sufficient, since it will not catch an problem which happened in the wild. but it might be unclear what I am trying to explain with the logging, so let me maybe to that part myself.
This pull request introduces 2 alerts and fixes 6 when merging e78527a into e71a9cd - view on LGTM.com new alerts:
fixed alerts:
|
I would not necessarily deal with this for 21.05 |
I just merged master and better coverage testing to see how far it is, and it is not too close anymore. Perhaps it's too much effort right now. I hope no merges were destructive. |
Thanks! It is not necessary at the moment. So it can be labelled as an enhancement and we can deal with that at a later stage after the release. |
This pull request introduces 1 alert and fixes 1 when merging 4b59ce3 into 8e979a1 - view on LGTM.com new alerts:
fixed alerts:
|
Refactoring ongoing