-
Notifications
You must be signed in to change notification settings - Fork 9
QLS: test that we do not swallow exceptions #587
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
c604654 to
cea8219
Compare
9354949 to
72f7383
Compare
6ac95c6 to
7c84a2a
Compare
72f7383 to
ba32682
Compare
|
BTW, this PR depends on #578 being reviewed and merged first. |
7c84a2a to
0969c5a
Compare
ba32682 to
6243344
Compare
6a3249b to
3e074a6
Compare
dcoutts
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking very good.
| -- restrictive, but this automatically improves as we make more actions | ||
| -- exceptions safe. When we generate injected errors for these errors by default | ||
| -- (in @arbitraryWithVars@), the swallowed exception assertion automatically | ||
| -- runs for those actions as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the motivation behind only running the action with a definite error last?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's mentioned in the text above this TODO: database behaviour should be considered undefined after an exception is thrown in exception unsafe code. If we run more actions afterwards, the SUT and model are almost certainly going to disagree on their responses
|
#607 is now in the merge queue, so this can be rebased on that. |
f60ace5 to
ff129e7
Compare
dcoutts
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes based on review feedback look good.
Squash the fixups and merge! 😄
We will be testing that `lsm-tree` operations do not swallow errors by injecting errors into the simulated file system and checking after the fact whether we should have seen an exception or not. One way to check this would be to compare the `Errors` structure before and after the `lsm-tree` operations, but this is unfortunately not possible in general. `Errors` are potentially infinite structures, which means computing a comparison on `Errors` may diverge. Instead, what we do is we create an `ErrorsLog` structure that records errors as soon as they are injected. We can inspect this log to see if any errors were swallowed.
When we start testing that errors are not swallowed by `lsm-tree`, we'll be injecting errors into bits of code that are not exception safe (yet). As a result, the checks mentioned in the commit title would lead to property failures. However, we just want to test that errors are not swallowed, so we make these checks configurable. File system checks, cleanup checks, and reference checks can enabled/disabled independently.
This property runs a sequence of state machine actions where the last action definitely injects errors, at which point we can check if no errors are swallowed. See the documentation of `prop_noSwallowedExceptions` for more information. The property is currently expected to fail.
We replace the assertions by pure responses that are checked against the model.
ff129e7 to
4e62a8a
Compare
This PR adds
fs-simfs-sim. That is, the assertion checks that no noisy errors are swallowed.DL) formula that injects errors into alllsm-treeactions and runs the swallow error assertion afterwards.