BF: Retain git-annex error messages & don't show them if operation successful by DisasterMo · Pull Request #6070 · datalad/datalad

DisasterMo · 2021-10-12T15:41:13Z

Description

Instead of being mashed into a 'normal' message, git-annex reported error messages will now be retained in a separate dict entry.
This allows for more differentiated handling of them. Examples implemented in this PR:

To avoid confusion, git-annex error messages will only be rendered if they are meaningful, i.e. when the operation actually failed.
Error messages are now grouped separately from notes & coloured red.

Related Issues

mih

Thx! I like the direction.

Looking at the test failures, I think they are legit. Some tests expect the error messages to be rendered/provided specifically as they were. Those need to be adjusted.

The PR also includes a number of unrelated formatting changes. I personally very much appreciate this type of cleanup. However, I would prefer to separate no-op formatting changes from topical changes in separate commits. Future forensics will be more straightforward. Not need to disentangle them for this one, just mentioning it.

datalad/interface/clean.py

DisasterMo · 2021-10-13T06:46:27Z

Some tests expect the error messages to be rendered/provided specifically as they were. Those need to be adjusted.

On it. I should probably run the tests myself before I submit a PR in the future, huh.

The PR also includes a number of unrelated formatting changes.

Yeah, I had PyCharm do it's magic a couple of times out of habit, sorry.

bpoldrack · 2021-10-13T08:46:07Z

datalad/interface/results.py

                           if not k.endswith('lastchanged')}
    if d.get('error-messages', None):
-        messages.extend(d['error-messages'])
+        res['error_message'] = '\n'.join(m.strip() for m in d['error-messages'])


I wonder whether such a join should only happen in result renderer(s). When using the python interface it may be beneficial to have a structured record in error_message.

I merely reproduced what was already being done a couple of lines below:

if messages: res['message'] = '\n'.join(m.strip() for m in messages)

Q is what are the semantics here? Do we know that this is one message with several lines, or several messages. So far the the message key had one purpose: carry a message to be displayed. If it shall become a message-building toolkit instead, we should work this out properly in #6054, and not introduce things in a single location, just for annex messages.

codecov · 2021-10-13T09:13:34Z

Codecov Report

Merging #6070 (723949c) into maint (3269925) will decrease coverage by 1.82%.
The diff coverage is 83.33%.

❗ Current head 723949c differs from pull request most recent head fcc2a2d. Consider uploading reports for the commit fcc2a2d to get more accurate results

@@            Coverage Diff             @@
##            maint    #6070      +/-   ##
==========================================
- Coverage   90.25%   88.43%   -1.83%     
==========================================
  Files         312      312              
  Lines       42214    42217       +3     
==========================================
- Hits        38099    37333     -766     
- Misses       4115     4884     +769

Impacted Files	Coverage Δ
datalad/core/local/tests/test_results.py	`100.00% <ø> (ø)`
datalad/distributed/tests/test_ria_git_remote.py	`100.00% <ø> (ø)`
datalad/interface/clean.py	`83.33% <ø> (ø)`
datalad/interface/results.py	`96.94% <66.66%> (-0.73%)`	⬇️
datalad/interface/utils.py	`95.32% <100.00%> (+0.01%)`	⬆️
datalad/version.py	`0.00% <0.00%> (-100.00%)`	⬇️
datalad/plugin/wtf.py	`0.00% <0.00%> (-100.00%)`	⬇️
datalad/plugin/addurls.py	`0.00% <0.00%> (-100.00%)`	⬇️
datalad/plugin/no_annex.py	`0.00% <0.00%> (-100.00%)`	⬇️
datalad/plugin/add_readme.py	`0.00% <0.00%> (-100.00%)`	⬇️
... and 60 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 3269925...fcc2a2d. Read the comment docs.

DisasterMo · 2021-10-13T09:59:31Z

Regarding AppVeyor error:

AssertionError: '<action-unspecified>(<status-unspecified>):\r\n[funky]' not found in '<action-unspecified>(<status-unspecified>):\n\n[funky]\n'

I use os.linesep in both cases, how can one be \r\n while the other is \n\n?

bpoldrack · 2021-10-13T10:42:10Z

@DisasterMo

I use os.linesep in both cases, how can one be \r\n while the other is \n\n?

That's strange indeed. I vaguely remember running into this bc of some meant-to-be-convenient- but-actually-confusing auto conversion python3 does when reading/writing files. Like reading \r\n and returning a string with \n.
The swallow_* helpers do involve writing the outputs to a file (or IO stream). Hence, I'd assume the effect happens within those, not your diff. However, note that the generic test would iterate over the to be matched output list. You could simply provide both lines separately. It would effectively not test for the line separation as assert_in would be true either way, but good enough, I think.

yarikoptic · 2021-10-13T13:27:24Z

Windows?

mih

OK, so with this PR I see:

{                                                                                                                           
  "action": "get",
  "annexkey": "MD5E-s32338--3cb12b68abd59160dffdf4830e1de8bb.nii.gz",
  "error_message": "download failed: Not Found\nfailed to download content\ndownload failed: Not Found\nfailed to download content\ndownload failed: Not Found\nfailed to download content",
  "path": "/tmp/studyforrest-data/derivative/aggregate_fmri_timeseries/sub-10/atlases/bold3Tp2/shen_fconn_atlas_150.nii.gz",
  "refds": "/tmp/studyforrest-data",
  "status": "ok",
  "type": "file"
}

rendered as

get(ok): derivative/aggregate_fmri_timeseries/sub-10/atlases/bold3Tp2/shen_fconn_atlas_150.nii.gz (file)                    
[download failed: Not Found
failed to download content
download failed: Not Found
failed to download content
download failed: Not Found
failed to download content]

which doesn't match the "& don't show them if operation successful" part of the PR title. Is that intentional?

If so, maybe a message prefix ala "intermediate errors occurred: " or something along these lines.

Also I would personally prefer no preemptive linebreaks in the reporting (i.e. before the [)

mih · 2021-10-14T10:59:05Z

datalad/interface/results.py

                           if not k.endswith('lastchanged')}
    if d.get('error-messages', None):
-        messages.extend(d['error-messages'])
+        res['error_message'] = '\n'.join(m.strip() for m in d['error-messages'])


Q is what are the semantics here? Do we know that this is one message with several lines, or several messages. So far the the message key had one purpose: carry a message to be displayed. If it shall become a message-building toolkit instead, we should work this out properly in #6054, and not introduce things in a single location, just for annex messages.

DisasterMo · 2021-10-14T14:28:27Z

which doesn't match the "& don't show them if operation successful" part of the PR title. Is that intentional?

Absolutely not. I had multiple versions of this code before submitting the PR, and somewhere in the middle the "test" I used (from #5617) stopped working for me. I must have forgotten to re-add the status check at some point after that & didn't notice.

DisasterMo · 2021-10-14T14:30:23Z

Also I would personally prefer no preemptive linebreaks in the reporting (i.e. before the [)

Why? From what I can tell, it is pretty obvious that any message is supposed to be a multi-line block. Personally, I find it incredibly ugly to see a multi-line block not start on a new line.

DisasterMo · 2021-10-14T14:38:13Z

what are the semantics here? Do we know that this is one message with several lines, or several messages.

The original error-messages contains, in general, multiple messages each with at least one line. We can distinguish lines, but not messages. So the general form of d['error-messages'] looks something like this:
["err1line1", "err2line2", "err2line1", ... , "errNlineM"]

mih

OK, this now works as advertised, thx much!

Also I would personally prefer no preemptive linebreaks in the reporting (i.e. before the [)

Why? From what I can tell, it is pretty obvious that any message is supposed to be a multi-line block. Personally, I find it incredibly ugly to see a multi-line block not start on a new line.

Actually, no. Overall, most messages are quite concise single line statements. Now they are forced on a separate line. The [ ... ] format was originally chosen to have some kind of a line/result-continuation indicator.

If the format of the default result rendering is to be changed, I think there should be a dedicated issue about this, and a separate fix -- not piggy-backing on an unrelated change.

…ccessful

mih

Great, thx for the update. Please feel free, and encouraged to propose a format change for the default renderer output!

DisasterMo changed the base branch from master to maint October 12, 2021 16:56

mih reviewed Oct 13, 2021

View reviewed changes

datalad/interface/clean.py Show resolved Hide resolved

mih mentioned this pull request Oct 13, 2021

Unconditional use of annex.retry turns error reporting into a mess #5808

Closed

bpoldrack reviewed Oct 13, 2021

View reviewed changes

DisasterMo force-pushed the bf-5617-duplicate-fail-messages branch from 5246dfc to d223782 Compare October 13, 2021 13:28

mih added the semver-patch Increment the patch version when merged label Oct 13, 2021

DisasterMo force-pushed the bf-5617-duplicate-fail-messages branch from d223782 to 477d86e Compare October 14, 2021 10:36

mih mentioned this pull request Oct 14, 2021

ORA accesses non-URL, and signals foreseeable(?) error datalad/datalad-ria#24

Open

mih requested changes Oct 14, 2021

View reviewed changes

mih requested changes Oct 15, 2021

View reviewed changes

DisasterMo force-pushed the bf-5617-duplicate-fail-messages branch 3 times, most recently from 70f3d53 to 6962030 Compare October 15, 2021 08:13

BF: Retain git-annex error messages & don't show them if operation su…

fcc2a2d

…ccessful

DisasterMo force-pushed the bf-5617-duplicate-fail-messages branch from 6962030 to fcc2a2d Compare October 15, 2021 08:14

mih approved these changes Oct 15, 2021

View reviewed changes

mih merged commit b33cf83 into datalad:maint Oct 15, 2021

mih mentioned this pull request Nov 1, 2021

A successful datalad get can still look quite sad #5617

Closed

Conversation

DisasterMo commented Oct 12, 2021

Description

Related Issues

Uh oh!

mih left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

DisasterMo commented Oct 13, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bpoldrack Oct 13, 2021

Choose a reason for hiding this comment

Uh oh!

DisasterMo Oct 13, 2021

Choose a reason for hiding this comment

Uh oh!

mih Oct 14, 2021

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Oct 13, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

DisasterMo commented Oct 13, 2021

Uh oh!

bpoldrack commented Oct 13, 2021

Uh oh!

yarikoptic commented Oct 13, 2021

Uh oh!

mih left a comment

Choose a reason for hiding this comment

Uh oh!

mih Oct 14, 2021

Choose a reason for hiding this comment

Uh oh!

DisasterMo commented Oct 14, 2021

Uh oh!

DisasterMo commented Oct 14, 2021

Uh oh!

DisasterMo commented Oct 14, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mih left a comment

Choose a reason for hiding this comment

Uh oh!

mih left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

DisasterMo commented Oct 13, 2021 •

edited

Loading

codecov bot commented Oct 13, 2021 •

edited

Loading

DisasterMo commented Oct 14, 2021 •

edited

Loading