Spurious per_interrepository.test_fetch.TestInterRepository. test_fetch_parent_inventories_at_stacking_boundary_smart_old failures
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
High
|
Unassigned | ||
Breezy |
Fix Released
|
Medium
|
Unassigned | ||
bzr (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
The daily builds are occasionally getting a spurious test failure:
=======
ERROR: bzrlib.
-------
_StringException: log: {{{
326.165 creating repository in bzr://127.
326.193 creating branch <bzrlib.
326.219 preparing to commit
326.238 Selecting files for commit with filter None
326.302 preparing to commit
326.316 Selecting files for commit with filter None
326.410 preparing to commit
326.419 Selecting files for commit with filter None
326.519 preparing to commit
326.519 commit parent revision {right}
326.532 Selecting files for commit with filter None
326.621 creating repository in bzr://127.
326.647 creating branch <bzrlib.
326.657 Using fetch logic to copy between RemoteRepositor
326.665 fetching: <SearchResult search:
326.667 Traceback (most recent call last):
File "/build/
_StatefulDe
File "/build/
self.
File "/build/
self.done()
File "/build/
raise errors.
SmartMessageHan
Traceback (most recent call last):
File "/build/
self.
File "/build/
"Complete conventional request was received, but request "
SmartProtocolError: Generic bzr smart protocol error: Complete conventional request was received, but request handler has not finished reading.
}}}
traceback-5: {{{
Traceback (most recent call last):
File "/build/
self.
File "/build/
trunk.
File "/build/
find_
File "/build/
result = unbound(self, *args, **kwargs)
File "/build/
find_
File "/build/
self.__fetch()
File "/build/
self.
File "/build/
stream, from_format, [])
File "/build/
(verb, path, '') + lock_args, byte_stream)
File "/build/
expect_
File "/build/
expect_
File "/build/
self.
File "/build/
self.
File "/build/
"Unexpected end of message. "
ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
}}}
-------
Related branches
- Jelmer Vernooij (community): Approve
-
Diff: 15 lines (+4/-1)1 file modifiedbzrlib/tests/per_interrepository/test_fetch.py (+4/-1)
tags: | added: babune selftest test-failure |
summary: |
- Spurious test failure + Spurious + per_interrepository.test_fetch.TestInterRepository.test_fetch_parent_inventories_at_stacking_boundary_smart_old + failures |
summary: |
- Spurious - per_interrepository.test_fetch.TestInterRepository.test_fetch_parent_inventories_at_stacking_boundary_smart_old - failures + Spurious per_interrepository.test_fetch.TestInterRepository. + test_fetch_parent_inventories_at_stacking_boundary_smart_old failures |
tags: | added: check-for-breezy |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | removed: check-for-breezy |
Changed in bzr: | |
status: | Confirmed → Fix Released |
Changed in brz: | |
status: | Triaged → Fix Released |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/14/2011 2:32 PM, Jelmer Vernooij wrote:
> Public bug reported:
>
> The daily builds are occasionally getting a spurious test failure:
>
This had been happening on Babune, which caused me to introduce this
change:
6197 Patch Queue Manager 2011-10-06 [merge] tests/test_ server. py' tests/test_ server. py 2011-10-03 14:15:44 +0000 tests/test_ server. py 2011-10-05 15:01:54 +0000
return
(jameinel) Allow for some tests to run slowly under load. (John
A Meinel)
=== modified file 'bzrlib/
--- bzrlib/
+++ bzrlib/
@@ -616,7 +616,7 @@
- _DEFAULT_ TESTING_ CLIENT_ TIMEOUT = 4.0 _DEFAULT_ TESTING_ CLIENT_ TIMEOUT = 60.0
+
class TestingSmartSer ver(TestingThre adingTCPServer, SmartTCPServer) :
server.
So if they are still failing, that would indicate the single test is
taking more than 1 minute to complete.
Note that if this really is the failure, the connection retry code
that I wrote should also handle this by just retrying from the client
side.
Though in that traceback there isn't a ConnectionTimeout. Instead it
looks like one side just closes the connection.
Specifically, it looks like the client sends some data, and indicates
that the message is done. The server reads this information, but feels
there is more that needs to be said, and raises an exception, closing
the connection to the client.
Now, if the client is genuinely sending a malformed message, that is
how it is supposed to work.
If find it odd that the test highlighted here is also the one that was
failing because of timeouts, though.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk6 dXcIACgkQJdeBCY SNAAOqnwCfbWQEK oui8be0OgQdtris Fl8v GmFh7j8xm43F0p8 hh
oCUAoKgRrbywsXv
=062Z
-----END PGP SIGNATURE-----