Avoid intermittent test failures in constrained-generators

[neilmayhew]

Description

Use QC.discardAfter instead of QC.within in prop_univSound. This treats a timeout as a discard rather than a failure. If the test consistently times out, the discard limit will be reached and the test will then fail.

Double the timeout in prop_univSound

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages.
  New section is never added with the code changes. (See RELEASING.md)
• When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
  versioning process.
• The version bounds in .cabal files for all affected packages are updated.
  If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• Code is formatted with fourmolu (use scripts/fourmolize.sh)
• Cabal files are formatted (use scripts/cabal-format.sh)
• hie.yaml has been updated (use scripts/gen-hie.sh)
• Self-reviewed the diff

[lehins]

Unfortunately this is not the right approach.

The main reason why within is used is to catch infinite loops. Discarding a test failure that leads to an infinite loop would effectively hide that bug. We've discussed this issue today in the meeting and more sensible solution is just double the time limit. Such solution has less dangers associated with it.

[neilmayhew]

The main reason why within is used is to catch infinite loops. Discarding a test failure that leads to an infinite loop would effectively hide that bug.

I wondered about that, but as I said in the description, "If the test consistently times out, the discard limit will be reached and the test will then fail." However, that wouldn't catch the case where the loop is infinite only sometimes.

We've discussed this issue today in the meeting and more sensible solution is just double the time limit. Such solution has less dangers associated with it.

OK, I'll change that.

[lehins]

However, that wouldn't catch the case where the loop is infinite only sometimes.

That is precisely the kind of bugs that we want to catch.

If a test case always results in an infinite loop then it is extremely easy to discover such problem without any special approaches.