TooManyConcurrentRequests error on commit when ssh auth fail (bzr 2.0)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
New
|
Undecided
|
Unassigned |
Bug Description
I tried to commit using qbzr but forget to add my key in pageant and got the error below. I frequently forgot to had my ssh ppk on the first commit every day, and it is the first time I got such a error. The bug disappeared after adding my ssh key.
I'm running on Windows XP SP3 with Bazaar stand-alone install.
Notes: there is similar existing bugs, but there are all indicated as fixed in pre-2.0 release from what I've seen.
E:\prg\
Connected (version 2.0, client Twisted)
bzr: ERROR: bzrlib.
host='
_reading on the currently open request.
Traceback (most recent call last):
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "C:/wut/
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
File "bzrlib\
TooManyConcurre
t', port=None)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently
open request.
bzr 2.0.0 on python 2.5.4 (Windows-
arguments: ['bzr', 'qsubprocess', '"commit" "-m" "Got simple hello world controller without template working." "gaetests
" "pylons/
l.py" "pylons/
ons/wsgiapp.py" "routes" ".bzrignore" "CHANGES.
ollers" "gaetests/public" "gaetests/
ers.py" "gaetests/main.py" "gaetests/
.py" "routes/mapper.py" "routes/
ontrollers/
gaetests/
encoding: 'cp1252', fsenc: 'mbcs', lang: None
plugins:
bzrtools C:\wut\
explorer C:\wut\
fastimport C:\wut\
launchpad C:\wut\
netrc_
qbzr C:\wut\
rebase C:\wut\
svn C:\wut\
upload C:\wut\
xmloutput C:\wut\
*** Bazaar has encountered an internal error. This probably indicates a
bug in Bazaar. You can help us fix it by filing a bug report at
https:/
including this traceback and a description of the problem.
This was fixed in trunk, and part of the 2.1.0b2. I'm a bit hesistant to backport it to the 2.0.x branch because the patch is a touch large and 2.0.x is a stable branch... but it is a pretty straightforward change despite the line-count, so we can consider it.
Anyhow, this bug is a duplicate, so I'm marking it as such.