I'm using Git for Windows 2.18.0.windows.1, recently updated this weekend, with credential-manager version 1.16.2. I have had no Git password issues for a year or two. Git has been working fine all weekend after the upgrade. I'm currently on a plane using the GoGo Internet service, which drops occasionally.
I went into a repository and did a git pull and got the latest version of master (many commits) with no problems. A new remote branch also came down, so I created a local branch tracking the remote branch and switched to it.
Then I issued git pull again. After some waiting, Git says:
fatal: TaskCanceledException encountered.
A task was canceled.
Then it waits a while and says:
fatal: TaskCanceledException encountered.
A task was canceled.
The second time it asks for my password:
Password for 'https://[email protected]':
This is particularly odd, as normally the credential manager pops up a window rather than asking me on the command line.
My .gitconfig has:
[credential]
helper = manager
Now Git refuses to do a pull, even though my Internet connection is working (as evidenced by this ticket I'm opening).
What do I do now?
I just tried with TortoiseGit 2.6.0.0, and the pull happened with no problems. (It appears that TortoiseGit used the command git.exe pull --progress -v --no-rebase "origin".)
I went back to the command line, and now git pull completes with no messages!
Either some sort of connection issue resolved itself for all Git clients, or TortoiseGit reset something that fixed the problem.
In any case, the error message doesn't help me much to know what happened.
@garretwilson the issue, likely, is that one of the round-trips the GCM needs to do to determine state, provider, etc. failed due to network flakiness. The GCM usually retries a couple of times, but it'll eventually give up and you'll see the TaskCancelledException message.
You see the dual attempt because Git does that now - not quite sure when that changed.
I just had the same issue. I was using my home wifi connection. Everything with the connection seemed fine.
I was only able to resolve the issue after switching from the 5ghz band to the 2.4ghz band. Once I successfully pushed, I was able to get back to normal even after switching back to the 5ghz band. Very weird.
I'm having similar issues. Git is trying two times, no modal login and then I get the command prompt to login:
C:\Users\david.p\Projects\shopify-sap-docker>git pull origin develop
fatal: TaskCanceledException encountered.
A task was canceled.
fatal: TaskCanceledException encountered.
A task was canceled.
Username for 'https://github.com':
Here is the relevant logs info:
git version 2.18.0.windows.1
Git Credential Manager for Windows version 1.16.2
11:13:46.262847 ...\Common.cs:84 trace: [CreateAuthentication] detecting authority type for 'https://github.com/'
.
11:13:46.292848 ...uthentication.cs:151 trace: [GetAuthentication] created GitHub authentication for 'https://github.com
/'.
11:13:46.292848 ...\Common.cs:161 trace: [CreateAuthentication] authority for 'https://github.com/' is GitHub.
11:13:46.302848 ...seSecureStore.cs:195 trace: [ReadCredentials] credentials for 'git:https://github.com' read from stor
e.
11:13:46.302848 ...uthentication.cs:175 trace: [GetCredentials] credentials for 'https://github.com/' found.
11:14:28.431779 ...\Git\Trace.cs:139 trace: [WriteException] ! error: 'A task was canceled.'.
11:14:28.431779 ...\Common.cs:630 trace: [LogEvent] System.Threading.Tasks.TaskCanceledException: A task was cance
led.
11:14:28.431779 ...\Program.cs:578 trace: [Run] fatal: TaskCanceledException encountered.
A task was canceled.
@vwroad87 I thinking that this is a time out issue - there's a 15 second limit on the HTTP interactions in the GCM. If you know how to compile and deploy C# code, then I suggest you try recompiling the GCM with Microsoft.Alm.Authentication.Global.RequestTimeout set to 5 minutes or something, and see if that resolves the issue for you.
Here are the timeouts i in the project, 15 seconds does seems reasonable
for a web request. What am I missing?
And yes I can recompile and deploy
C:\Users\david.p\Projects\Git-Credential-Manager-for-
Windows\Microsoft.Alm.Authentication\Src\Global.cs(40): public const
int RequestTimeout = 15 * 1000; // 15 second limit
C:\Users\david.p\Projects\Git-Credential-Manager-for-Windows\GitHub.Authentication\Src\Authority.cs(48):
public const int RequestTimeout = 15 * 1000; // 15 second limit
C:\Users\david.p\Projects\Git-Credential-Manager-for-Windows\Bitbucket.Authentication\Src\Authority.cs(50):
public const int RequestTimeout = 15 * 1000; // 15 second limit
C:\Users\david.p\Projects\Git-Credential-Manager-for-Windows\Bitbucket.Authentication\Src\OAuth\OAuthAuthenticator.cs(46):
public const int RequestTimeout = 15 * 1000; // 15 second limit
On Tue, Jul 17, 2018 at 2:10 PM, J Wyman notifications@github.com wrote:
@vwroad87 https://github.com/vwroad87 I thinking that this is a time
out issue - there's a 30 second limit on the HTTP interactions in the GCM.
If you know how to compile and deploy C# code, then I suggest you try
recompiling the GCM with Microsoft.Alm.Authentication.
Global.RequestTimeout set to 5 minutes or something, and see if that
resolves the issue for you.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/Git-Credential-Manager-for-Windows/issues/665#issuecomment-405729034,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJjT4-UWXAzf7EctYnCGd4AnYH5TlV-3ks5uHlK8gaJpZM4U4q8A
.
What am I missing?
Looks like the correct code snipit. I'd just change the 15 * 1000; // 15 second limit to 300 * 1000; // 5 minute limit, recompile (Release) then run the GCMW-v1.17.0.exe that should be placed in the solution's Deploy/ folder.
I guess I can't create the GCMW-... with MVS Community 2017? All it seems to produce is the .dll files and tests. I'm not a MVS wizard though. I did do a search and replace for the locations of the .dll file and all that changed was the timeout until a the cli credential prompt appeared?
The *.dll and *.exe contents of "{solution_root}\Cli\Manager\bin\Debug\" can be manually copied over their equivalents in "{path_to_git}\mingw64\libexec\git-core\" and you'll have a working version.
Okay so this is a different issue, check the log and see the long timeouts, I set the timeout to 1 minute to test instead of 5. The wtire exception is gone and the pull completes without me having to put in credentials.
@vwroad87 @JustMaier @garretwilson I'll get a fix ready for the v1.17.0 preview, and hopefully you can all validate that the issue is resolved.
@vwroad87 thanks so much for doing the leg work on this - very much appreciated!
I encountered the same issue and a search directed me here. Glad you guys have already pinned this down. Where or when can I download the patched version?
@nilnul I do not have a signed build ready yet, a few issues were reported in the current preview and I'd like to get them all ironed out before releasing the next preview. My hope is to have the next (and please let this be the final) preview releases on Mon 23 Jun 2018 (EST).
glad to hear so. and can I just make this configurable? Just asking.
Should this issue be fixed in v1.17.0-preview.5?
I'm still suffering from this and it's really annoying because my auto builder scripts are useless now.
@akuukka yes, is should be.
this exception happens more often for bitbucket.org; and generally no such exception for other servers such as gitlab. Does this mean connection with bitbucket takes more time?
glad to hear so. and can I just make this configurable?
That's not a bad idea. Would you mind filling an issue for the feature request?
Does this mean connection with bitbucket takes more time?
Yes. For whatever reason, Bitbucket is noticeably slower for me as well (though, not quite as slow as reported here). It could be anything from network problems (like peering, throttling, bad hardware) to anti-maleware deciding it needs to deep-packet-sniff everything, to bugs in the Atlassian server software. There's no telling why - though, I tend to blame the telcos by default.
Oh no, suddenly this is happening with me connecting to Bitbucket with an 80Mbps fixed connection using version 2.18.0.windows.1. I can't even push now.
@garretwilson can you report the output of git version and git credential-manager version ?
If your GCM version is less than v1.17.0, could you try the v1.17.0 release?
@mminns @foda since yesterday, we (Visual Studio and GCM) have been seeing a ton of issue reported with Bitbucket authentication either timing out or failing due to connections being closed by the host. Do you know if anything has changed with Bitbucket or it network provider recently?
Not sure what's going on with Bitbucket, but recently I'm having authentication trouble with them even on Linux and especially with git lfs.
@whoisj I ping'd the Bitbucket team -- will let you know if I find out anything.
I don't have time to manually install a different GCM version right now.
I'm still unable to push to Bitbucket. I note that https://status.bitbucket.org/ still says that there are no problems.
I understand when a connection is bad and times out, but… this is only 2–3 seconds! This is surprising for two reasons:
Both of these together makes me suspect there is more going on here than meets the eye.
@garretwilson BB team doesn't have anything to report -- but I encourage you to file an issue with them and see if there an additional problem with your connection.
Ack! I can't even pull the latest code from my client! I will file a ticket with Bitbucket immediately, thanks.
The Bitbucket support rep apparently hasn't looked in to the network issue yet. He/she tells me to look at the notice at https://github.com/Microsoft/Git-Credential-Manager-for-Windows, and says it has been resolved with a new version of GCM.
That notice seems to be regarding GitHub dropping support for weak encryption. Is that even relevant here?
Now the BitBucket rep says s/he was wrong about the notification at https://github.com/Microsoft/Git-Credential-Manager-for-Windows ; this was irrelevant. Now s/he says that there is some "bug" in GCM for Windows. But s/he hasn't explained to me yet why my Git client is working for GitHub and not for Bitbucket.
I get the feeling that a buck is being passed. Harumph.
@garretwilson there was a nasty bug with Bitbucket support in v1.16.2. It was fixed via this issue in v1.17.0, but if you're using 2FA you'll have to wait a few days for the next fix
Maybe I'm being dense here, but if I haven't changed my client configuration in weeks, why was it working fine yesterday and suddenly stopped working completely today? If this "bug" was the source of the problem, the bug was there yesterday. What happened to make it suddenly appear? I'm confused.
Is there some sort of Bitbucket authentication token that perhaps only expired yesterday, requiring actual authentication renewal to only happen now? (I'm just trying to understand what's going on, because it doesn't make sense to me yet.)
Pushing to Bitbucket is still failing today, so I went ahead and upgraded to GCM for Windows 1.17.0. I then tried pushing, and I got a dialog asking for my Bitbucket credentials. I logged in using my Bitbucket username and password. Now the command line says:
Logon failed, use ctrl+c to cancel basic credential prompt.
And the git CLI is hung. What do I do now?
Apparently the CLI was hung because the Bitbucket authentication window popped up again, but behind all my other windows.
Nevertheless, I enter my Bitbucket username and password, and it still says my logon failed.
@garretwilson see #710 , #711, #712 . We're working on it! 😁
Was there ever any solution to this problem? It started happening to me recently.
Most helpful comment
@whoisj I ping'd the Bitbucket team -- will let you know if I find out anything.