Download session/credentials locking -- inform user if locking is "failing" to be obtained, fail upon ~5min timeout #5884
Conversation
… if failing Also allow for a mode to proceed_unlocked (not enabled by default) so we could indeed ignore locking in some circumstances where clearly something is just odd (should not take over 5 minutes to enter the password!)
…to acquire Since this locking was primarily introduced just to avoid multiple parallel processes querying for the same credential if it was not set etc, I think it would be just fine to proceed unlocked after the default 3 attempts taking 5 minutes. After initial 5 seconds user would be informed that locking is failing, and let user know the location of the lock, and even (where it can figure out) which processes have it. So, user should be free to finish/kill those processes or remove the lock having been given all information we could provide
yarikoptic
changed the title
yarikoptic
added
credentials
Codecov Report
@@ Coverage Diff @@
## maint #5884 +/- ##
==========================================
- Coverage 90.32% 82.73% -7.60%
==========================================
Files 300 297 -3
Lines 42396 42458 +62
==========================================
- Hits 38293 35126 -3167
- Misses 4103 7332 +3229
Continue to review full report at Codecov.
|
| assert_in(f'CWD={os.getcwd()} CMDLINE=', res['stderr']) | ||
| except AssertionError: | ||
| # we must have had the other one then | ||
| assert_in('failed to determine one', res['stderr']) |
There was a problem hiding this comment.
note: no coverage here is odd since it should be happening on OSX... aren't we pushing coverage from those???
There was a problem hiding this comment.
hm, looking at /mnt/btrfs/datasets/datalad/ci/logs/2021/08/12/pr/5884/9827dc3/github-Test on macOS-1723-success/test (brew)/9_Upload coverage report to Codecov.txt -- coverage is successfully uploaded, and points to https://codecov.io/github/datalad/datalad/commit/9827dc38edf72106d429ee78dfa8d632a92bed43 but that one is not "run specific". I wonder if combining from multiple submissions works correctly, or just the last one to arrive (travis? ;)) wins it all?
|
I think I feel brave enough with this to proceed against |
yarikoptic
added
the
merge-if-ok
|
I posted an extensive review yesterday. But there is no trace of it, wtf!? I have no time right now to rewrite it, but the bottom line was a "request changes", because ignoring locking in this fashion might pave over actual problems that we better get fixed. That being said, I unconditionally like the more informative output! |
Per @mih opinion and my agreement with that
Happens to the best of us (did you grow to carry over a dozen of tabs in the browser?).
I was on the edge in this but even though I thought to argue "but that is only for us to lock for credentials input!", experience in troubleshooting git-annex in #5400 (where git-annex tries to lock for quite a while to only give up eventually and proceed) kinda tilted me to the opinion, that yeah -- let's just error out so no such abnormal hard-to-debug cases emerge, and behavior would be somewhat consistent with current |
yarikoptic
changed the title
2 participants
I think it could be considered to resolve #5099 - user will be given INFO level log messages (just now realized -- may be the last one at least should be a warning??? or should we have a progress bar? ;-)) with all possible information we can provide, even which processes have that lock ATM (well -- might not universally work... windows - I am talking to you).
I also decided that "heck with that locking" if we fail to get the lock within 5 minutes! at least this way may be some processes would complete (but possibly hide the problem).
Please see individual commits for more information. It seems to come out to be again yet another "one time use locking helper", but since we have not come up with a better way to address this locking "issue", I think it is a small price to pay ;)
maintbut it grew a bit too big. I will be fine to reposition it againstmaster-- we should get one out of the door soon.