Anyway, I have now slimmed down the test_wild_monkey test a bit.

I already have updated the tests, so they will (hopefully) not time out. As I already mentioned the test_wild_monkey function
calls send and receive pretty often with pretty big loads of data, so it is no wonder that it is slow.

Why should I care about that now? The part about performance (minimizing data transmitted) is a bonus section

The bonus section is about the transmitted data size, not the code performance. Very slow code will time out and this has nothing to do with the task.
But I realize that my tests have exaggerated a bit.

I just found that I can look at your solution. You could still save quite a bit of time by saving up some allocations.
I'm not sure what you mean by "can't handle". Do you mean that it is extremely slow or that it is not doing its job properly?
And is the 10⁶ bytes the length of the return vector of asend call by test_wild_monkey?
Anyway, I have now slimmed down the test_wild_monkey test a bit.

the wild monkey function performs some load tests, including tests with rather large input vectors.
Could it be that you are outputting a vector that has a size of O(n^2) relative to the input vector, or even larger?
That would explain the timeout for me.

This is my first kata so I don't have any knowledge about the test system.
The timeout is not reproducible for me. Do the tests run on client side?

Oh, yeah, thanks, this will be a quick fix sweatsmile

You can't, but you can infer it based on the number of mines.
Let's take a test case where you have 6 mines.
If you solve the puzzle and use your second solution and
get minimum 7 mines, your second solution is impossible.
In your reply, this exactly is the case!