Investigate hanging tlsn/crates/tls/mpc/tests/test.rs

[th4s]

When running the tls-mpc-test with a tracing configuration that emits New and Close FmtSpans we were able to capture the following log trace_hang.txt.

After filtering for lines that contain decode_key_private and writing all these Leader events into this file
decode_key_private.txt and doing the same for decode_key_blind and writing these Follower events into this file decode_key_blind.txt I notice that decode_key_private is called twice on the Leader site (line 1 and 21). This is not true for the follower, where it is called only once (line 1). This is what causes the leader site to be hanging in ot_receive_active_encodings (line 14389 in trace_hang.txt).

The cause for this might be that commit which calls decode_key_privateis called twice:

• https://github.com/tlsnotary/tlsn/blob/dev/crates/tls/client-async/src/lib.rs#L179
• https://github.com/tlsnotary/tlsn/blob/dev/crates/tls/mpc/tests/test.rs#L194

[themighty1]

Most likelydecode_key_private is called twice due to a race.
It happens under these conditions:

• the Leader calls commit and causes the notifier to be set by self.notifier.set()

• we would hope that select_biased! in async-client would start processing the notify future

• but at the same time the server closes the connection and rx_tls_fut is processed instead which causes client.server_closed() to be called , which calls commit again while self.buffer is not empty.

The fix is to not allow commit to be called more than once, unless there is a reason to do so @sinui0

[th4s]

While working on #539 I encountered the same test hanging. I isolated it into a new investigation-branch.

• Please note that it is possible that since the new investigation-branch was branched off from Enable deferred-decryption per default #539 it is possible that the bug was introduced in Enable deferred-decryption per default #539.
• I applied a fix for the original problem described in this issue on investigation-branch, but the test still hangs. So it is possible that there is a different cause.

[th4s]

While working on #539 I encountered the same test hanging. I isolated it into a new investigation-branch.

This is fixed now and was caused by the changes of #539. But the original bug from the trace_hang.txt still needs to be adressed.

[th4s]

Closed by #568