Skip to content
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

interface: Include message in json{,_pp} output #5536

Merged
merged 2 commits into from Mar 30, 2021

Conversation

kyleam
Copy link
Contributor

@kyleam kyleam commented Mar 29, 2021

When rendering results as json, the message and logger fields are
dropped. Information about the logger seems unlikely to be useful,
but filtering out the message can lose information that's not
available elsewhere, particularly for commands that put a caught
exception in the message field of status=error results.

The message has been filtered out since result handling was introduced
in v0.6.0. 2747ed1 (RF: Centralize logging in result evaluation,
2017-03-02) doesn't give an explicit reason for this, but it's likely
because the message can be a (<format string>, <value>, ...) tuple,
and those values aren't necessarily JSON serializable. However, this
should no longer be an issue as of v0.11.0 because json.dumps() is
called with a default=str.

Retain the message in the json rendering to avoid losing information.

At least in the case of exceptions, another option would be to update
these commands to use a field that isn't dropped. get_status_dict()
recently gained an 'exception' keyword, which it formats as the
'exception_traceback' field, so this approach is already used to some
degree. Aside from backward compatibility concerns, the problem with
using a different field is that then callers using the default
renderer do not see the information.

Re: #5517 (comment)

When rendering results as json, the message and logger fields are
dropped.  Information about the logger seems unlikely to be useful,
but filtering out the message can lose information that's not
available elsewhere, particularly for commands that put a caught
exception in the message field of status=error results.

The message has been filtered out since result handling was introduced
in v0.6.0.  2747ed1 (RF: Centralize logging in result evaluation,
2017-03-02) doesn't give an explicit reason for this, but it's likely
because the message can be a `(<format string>, <value>, ...)` tuple,
and those values aren't necessarily JSON serializable.  However, this
should no longer be an issue as of v0.11.0 because json.dumps() is
called with a default=str.

Retain the message in the json rendering to avoid losing information.

At least in the case of exceptions, another option would be to update
these commands to use a field that isn't dropped.  get_status_dict()
recently gained an 'exception' keyword, which it formats as the
'exception_traceback' field, so this approach is already used to some
degree.  Aside from backward compatibility concerns, the problem with
using a different field is that then callers using the default
renderer do not see the information.

Re: datalad#5517 (comment)
@codecov
Copy link

codecov bot commented Mar 29, 2021

Codecov Report

Merging #5536 (6754f41) into master (43a60f2) will decrease coverage by 1.86%.
The diff coverage is n/a.

❗ Current head 6754f41 differs from pull request most recent head 97ae026. Consider uploading reports for the commit 97ae026 to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5536      +/-   ##
==========================================
- Coverage   90.28%   88.42%   -1.87%     
==========================================
  Files         299      296       -3     
  Lines       42449    42431      -18     
==========================================
- Hits        38327    37521     -806     
- Misses       4122     4910     +788     
Impacted Files Coverage Δ
datalad/interface/utils.py 94.85% <ø> (ø)
datalad/support/tests/utils.py 0.00% <0.00%> (-100.00%) ⬇️
datalad/metadata/extractors/tests/test_audio.py 19.35% <0.00%> (-80.65%) ⬇️
datalad/metadata/extractors/xmp.py 12.96% <0.00%> (-79.63%) ⬇️
datalad/metadata/extractors/exif.py 18.75% <0.00%> (-78.13%) ⬇️
datalad/metadata/extractors/image.py 19.35% <0.00%> (-77.42%) ⬇️
datalad/metadata/extractors/audio.py 20.00% <0.00%> (-77.15%) ⬇️
datalad/metadata/extractors/tests/test_exif.py 24.00% <0.00%> (-76.00%) ⬇️
datalad/metadata/extractors/tests/test_xmp.py 26.92% <0.00%> (-73.08%) ⬇️
datalad/metadata/extractors/tests/test_image.py 26.92% <0.00%> (-73.08%) ⬇️
... and 58 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 43a60f2...97ae026. Read the comment docs.

@kyleam
Copy link
Contributor Author

kyleam commented Mar 29, 2021

The AppVeyor failure is a known spurious failure (gh-5308)

Copy link
Member

@yarikoptic yarikoptic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say we go with this and see if anything really wild gets displayed returned ;-)

@mih mih merged commit 63cfc49 into datalad:master Mar 30, 2021
@kyleam kyleam deleted the results-json-keep-message branch March 30, 2021 12:52
kyleam added a commit to kyleam/datalad that referenced this pull request Mar 30, 2021
This was handled by the merge of dataladgh-5536.

[ci skip]
kyleam added a commit to kyleam/datalad that referenced this pull request Mar 30, 2021
This was handled by the merge of dataladgh-5536.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants