[PATCH] Attachments test fails due to identical timestamps

[james@…]

The Trac 'attachments' test adds two attachments to the database, and checks that they are added in the correct order (one after another). It checks this order by sorting the attachments by time. On fast machines, these two attachments are added to the database so quickly that they show up with exactly the same timestamp. As a result, the sort order is undefined and the test frequently fails.

To fix this test failure, I have added a two microsecond "sleep_for_timestamps" function. This ensures that the two attachments are added with different timestamps.

• trac/tests/util.py: (AttachmentTestCase.test_insert): Sleep for two microseconds in between adding new attachments so as to ensure different timestamps and a consistent ordering.
• trac/util.py: (sleep_for_timestamps): Add sleep_for_timestamps function.

trac/tests/attachment.py

@@ -2 +2 @@
 from trac.config import Configuration
 from trac.log import logger_factory
 from trac.test import EnvironmentStub, Mock
+from trac.util import sleep_for_timestamps
 
 import os
 import os.path
@@ -58 +59 @@
     def test_insert(self):
         attachment = Attachment(self.env, 'ticket', 42)
         attachment.insert('foo.txt', tempfile.TemporaryFile(), 0)
+        sleep_for_timestamps()
         attachment = Attachment(self.env, 'ticket', 42)
         attachment.insert('bar.jpg', tempfile.TemporaryFile(), 0)
 

trac/util.py

@@ -26 +26 @@
 import time
 import tempfile
 import re
+import time
 
 TRUE =  ['yes', '1', 1, 'true',  'on',  'aye']
 FALSE = ['no',  '0', 0, 'false', 'off', 'nay']
@@ -381 +382 @@
                     return '</span>'
                 return '<span class="code-%s">' % mtype
 
+def sleep_for_timestamps():
+  granularity = 0.002
+  time.sleep(granularity)

[anonymous]

Patch to solve this issue

[james@…]

Looks like the patch got mangled in the text of the report, so I attached it as "patch.txt".

Cheers,

David James

[james@…]

We should probably increase the sleep there from 0.002 to 0.02. I've found that 2 milliseconds isn't enough — we need at least 1/60th of a second to ensure safe timestamps.

[Christian Boos]

I just upgraded to pysqlite2 2.0.4 … and got hit by this one :)

[Christian Boos]

Applied in r2310. Thanks!

(and sorry for not having done that earlier, you told me about it in July, IIRC :) )