launchpad-reviewers team mailing list archive

[Colin Watson <mp+419215@xxxxxxxxxxxxxxxxxx>]

Colin Watson has proposed merging ~cjwatson/launchpad:flaky-adapter-tests into launchpad:master.

Commit message:
Fix flaky database adapter doctests

Requested reviews:
  Launchpad code reviewers (launchpad-reviewers)

For more details, see:
https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/419215

`lib/lp/services/webapp/doc/test_adapter.txt` had several transient failures on buildbot, due to being overly sensitive to the test system's clock.
-- 
Your team Launchpad code reviewers is requested to review the proposed merge of ~cjwatson/launchpad:flaky-adapter-tests into launchpad:master.

diff --git a/lib/lp/services/webapp/doc/test_adapter.txt b/lib/lp/services/webapp/doc/test_adapter.txt
index d19dfa3..d2017af 100644
--- a/lib/lp/services/webapp/doc/test_adapter.txt
+++ b/lib/lp/services/webapp/doc/test_adapter.txt
@@ -173,7 +173,7 @@ the Postgres statement timeout (a value of zero means no timeout):
     >>> def current_statement_timeout(store):
     ...     result = store.execute('SHOW statement_timeout')
     ...     timeout = result.get_one()[0]
-    ...     # convert to miliseconds and round value to nearest 10ms
+    ...     # convert to milliseconds and round value to nearest 10ms
     ...     if timeout == '0':
     ...         timeout = 0
     ...     elif timeout.endswith('ms'):
@@ -198,6 +198,19 @@ the Postgres statement timeout (a value of zero means no timeout):
     >>> clear_request_started()
 
 
+The statement_timeout will be adjusted during the transaction, within
+a certain precision. To test this reliably, we need a time machine to
+avoid random failures under load. Lets build one and plug it in:
+
+    >>> _now = 0
+    >>> def fake_time():
+    ...     return float(_now)
+    >>> def time_travel(delta):
+    ...     global _now
+    ...     _now += delta
+    >>> lp.services.webapp.adapter.time = fake_time # Monkey patch
+
+
 Using the builtin pg_sleep() function, we can trigger the
 timeout by sleeping for 200ms with a 100ms statement timeout:
 
@@ -237,18 +250,6 @@ set_request_started() is called in scripts.
     >>> store.execute('SELECT pg_sleep(0.200)', noresult=True)
     >>> clear_request_started()
 
-The statement_timeout will be adjusted during the transaction, within
-a certain precision. To test this reliably, we need a time machine to
-avoid random failures under load. Lets build one and plug it in:
-
-    >>> _now = 0
-    >>> def fake_time():
-    ...     return float(_now)
-    >>> def time_travel(delta):
-    ...     global _now
-    ...     _now += delta
-    >>> lp.services.webapp.adapter.time = fake_time # Monkey patch
-
 
 Now issue three statements, the first one taking less than the precision
 time but the second going over the threshold. We use the time machine
@@ -352,12 +353,12 @@ another query:
     ...
     lp.services.webapp.adapter.RequestExpired: request expired.
 
-The statement about to be executed is not recorded in the statement log.
-The request time limit was exceeded before the statement was issued to
-the database.
+The statement about to be executed is recorded in the statement log, even
+though the request time limit was exceeded before the statement was issued
+to the database.
 
     >>> print(pretty(get_request_statements()))
-    [(0, ..., 'SQL-main-primary', 'SELECT 2', ...)]
+    [(..., ..., 'SQL-main-primary', 'SELECT 2', ...)]
 
 
 When a RequestExpired exception is raised, the current