fix(torture): handle large overflow values

[gabriele-0201]

Spawning a blocking task to handle the reception of the message is a workaround to make it possible to handle large overflow values.
Using the standard timeout(self.shared.timeout, rx).await??; does not work, it hangs when the expected value to be received is larger than 15KiB.

The problem seems to be strictly related to the interaction between tokio::time::timeout and tokio::sync::oneshot::Receiver.

A simple code like the following perfectly works.

      let message = loop {
          tokio::time::sleep(Duration::from_millis(1)).await;
          if let Ok(something) = rx.try_recv() {
              break something;
          }
      };

It seems that the Future implementation of tokio::sync::oneshot::Receiver switches from being non-blocking to blocking if the size of the message gets bigger than 15KiB.

But I also found this, which is a bug within the timeout function in a couple of versions ago (solved in 1.38.1, we are in 1.42), maybe it is not entirely solved.

[gabriele-0201]

• chore(torture): address multiple left todos #725
• refactor(torture): allow long rollback tests #723
• refactor(torture): probabilities handling #717
• feat(torture): add rollback crash #716
• fix(torture): move snapshot check #713
• feat(torture): add sample-snapshot option #712
• fix(torture): handle large overflow values #711 👈 (View in Graphite)
• chore(torture): update some names #707
• feat(torture): add rollback #706
• feat(torture):optional checks after commit & crash #704
• feat(torture): ensure snapshot after every crash #703
• feat(torture):reverted changeset on previous state #702
• refactor(torture): use OrdMap to track the state #701
• feat(torture): sample state after commit #700
• feat(torture): crash after average commit time #698
• feat(torture): add commit crash bias #697
• feat(torture): add WorkloadParams to cli #696
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[pepyakin]

Workarounds is fine, but please please please, leave a note in the code explaining what they are doing.

If you don't do it, the next generation of maintainers (that might include yourself), will definitely get the "wtf is this shit" question, and they will try to remove this code, only to uncover this is for a reason. Another option is that some of us will remember that this is some workaround, but will not remember why, and as such will be reluctant to remove this workaround even when it's not needed.

I do not care about this particular case that much, I care about us aligning on the common approach writing and documenting code.

[gabriele-0201]

You are totally right! I really thought I had added the same text both in the pr description and in the code!
I will fix it right now!

[rphmeier]

Merge activity

• Jan 23, 2:16 PM EST: A user started a stack merge that includes this pull request via Graphite.
• Jan 23, 2:22 PM EST: Graphite rebased this pull request as part of a merge.
• Jan 23, 2:22 PM EST: A user merged this pull request with Graphite.