The problem is that the order in which referenceTree.add(x, y); and referenceTree.del(x); calls happen is unspecified, so I can get wrong referenceTree!
The question is how to fix this test bug.
I can’t put a lock around add and del calls, because it undetermines the purpose of my test: to run several add and delete operations simultaneously (to the point of them being run only between awaits, as usual).
As written, it looks like ‘add()’ and ‘dell()’ are both fire-and-forget in the sense that their caller cannot wait for them to complete. Is that intentional? To make them awaitable, they need to have an explicit ‘async ()’ return type
The IC is support to guarantee that messages from A to B arrive at B in the order sent from A.
Can you (perhaps) write a test driver A(B), that deterministically sends the desired sequence of messages to canister B, then run A(B1) and A(B2) and after both complete, compare the states of B1 and B2?
I understood nothing: What are B1 and B2? What is A(B)? Etc.
I think, I found solution to my problem: I will add function argument (only for testing) to add and del shared methods. This function will modify referenceTree. This seems the only way to make the order of operations in resultingTree and referenceTree match, because await is always non-deterministic.