Join GitHub today
progress: Track total times following redirects #1602
Update the progress timers
As a related change, rename
Added test case 1399.
Fixes #522 and Known Bug 1.8
Thanks for the review @bagder!
I've added the
A couple other items to flag in case they are issues:
I'll drop another note in this conversation once the new builds finish to confirm the
I noticed something interesting when looking into the issue of starttransfer being greater than total, and I could use some input on what the correct behavior is and/or how to further debug.
What I've found is that sometimes
Previously, capturing the time of
Even more interesting is that I can apply the same debug/logging code to
Conceptually, I wouldn't think it would be correct for
I agree that setting
I think the reason for the double setting is simply because the state in which it sets it doesn't change when set so it can detect a believed start situation again!
Makes sense to resolve before merging this PR. I'm happy to take a stab at it, though not being very familiar with the code I could use some guidance on what you think the best approach might be.
Do you think it's as simple as checking within
Or is the double invocation a symptom of a larger problem that needs to be solved? e.g., perhaps there's a bug in
Let me know your thoughts and I'll start working on this in a new issue/PR. Thanks!
referenced this pull request
Jun 26, 2017
added a commit
this pull request
Jun 30, 2017
I've updated this PR now that
f8f040e (progress: prevent resetting t_starttransfer) and related fixes for broken tests are in master.
The logic for handling multiple invocations of
TIMER_STARTTRANSFER had to change a bit: I've adding a bool to track whether we should be modifying t_starttransfer (or not if it is a repeated call for the same request).
Looking forward to your comments!