Page MenuHomePhabricator

tests: increase internal timeouts
AbandonedPublic

Authored by joerg.sonnenberger on Thu, May 7, 9:03 AM.

Details

Reviewers
None
Group Reviewers
hg-reviewers
Summary

The default limit is not enough time for non-rust test cases on a
Threadripper when using SMT, so bump the limit to 1/3 of the default
timeout to provide some breathing room.

Diff Detail

Repository
rHG Mercurial
Branch
stable
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

Can you double check that 20 second are actually spend to timeout? Previously we had a bug were the time waited was actually 0.2 seconds (and not 20 seconds) and the test was only "flacky". So spending more than 20 seconds in there seems pretty suspicious and I suspect another misbehaving. ?

Can you double check that 20 second are actually spend to timeout? Previously we had a bug were the time waited was actually 0.2 seconds (and not 20 seconds) and the test was only "flacky". So spending more than 20 seconds in there seems pretty suspicious and I suspect another misbehaving. ?

   $ date
+  Thu May  7 15:28:09 GMT 2020
   $ wait-on-file 20 sync-txn-pending && \
   > hg debugnodemap --metadata && \
   > wait-on-file 20 sync-txn-close sync-repo-read
+  file not created after 20 seconds: sync-txn-pending
+  data-length: 121280 (pure !)
+  data-length: 121280 (rust !)
+  data-unused: 192 (pure !)
+  data-unused: 192 (rust !)
+  data-unused: 0.158% (pure !)
+  data-unused: 0.158% (rust !)
+  [1]
+  $ date
+  Thu May  7 15:28:09 GMT 2020
+  $ hg debugnodemap --metadata

so it looks like we do have another wait-on-file bug, though I'm lost as to how.

(I don't have time to do this at the moment, but I strongly suspect we'd be better off with wait-on-file as a Python script at this point.)

joerg.sonnenberger abandoned this revision.Thu, May 7, 5:20 PM

Will fix the real problem.