Add a mechanism to block the slow path in tests #5539
Conversation
froydnj
left a comment
There was a problem hiding this comment.
This is a lot nicer than some of the other alternatives I was contemplating.
| slowPathBlockedMutex.Await(absl::Condition( | ||
| +[](bool *slowPathBlocked) -> bool { return !*slowPathBlocked; }, &slowPathBlocked)); |
There was a problem hiding this comment.
Looking at the abseil sources, it looks like this can just be:
| slowPathBlockedMutex.Await(absl::Condition( | |
| +[](bool *slowPathBlocked) -> bool { return !*slowPathBlocked; }, &slowPathBlocked)); | |
| slowPathBlockedMutex.Await(absl::Condition(&slowPathBlocked)); |
or did you try that already and found that it didn't work?
There was a problem hiding this comment.
Ooh, no, let me give it a shot!
There was a problem hiding this comment.
Ah, unfortunately this doesn't quite work because the condition we're waiting for is that slowPathBlocked is false, not true. I suppose we could change this internally, but on balance I think the extra complexity here is worth keeping "true means blocked" semantics on the surface and in the implementation. (Glad to change in a later PR if there's objections, though.)
| // We expect the slow path to be blocked, so we want to make sure that we _don't_ receive any messages within a | ||
| // pretty long time frame---let's say 2000ms. | ||
| { | ||
| auto &wrapper = dynamic_cast<MultiThreadedLSPWrapper &>(*lspWrapper); | ||
| auto msg = wrapper.read(2000); |
There was a problem hiding this comment.
...and yet, timeouts manage to sneak their way into the patch anyway. :)
There was a problem hiding this comment.
Yeah, so unsatisfying! At least there's only one instead of the dozens that #5469 would have needed, I s'pose :)
| return; | ||
| } | ||
|
|
||
| // Test-only hook: Stall for as long as `slowPathBlocked` is set. |
There was a problem hiding this comment.
WDYT about moving this below the ENFORCE(gs->lspQuery.isEmpty()); so it's sort of visually obvious that slowPathBlocked and sleepInSlowPath are doing the same-ish thing?
There was a problem hiding this comment.
Good call, will do
For the stale-state feature we need a way to block slow paths programmatically in tests.
Motivation
The immediate motivation is to get rid of reliance on (brittle, slow) sleeps in the protocol tests for #5469. We can also use this mechanism in the future to implement position assertion-style tests for stale-state queries.
Test plan
See included automated tests.