A day of mostly bugfixing. some days it feels the progress is slow, but getting things working completely is part of the process. usually the most time consuming.
We are also setting up some jenkins test points where a test point is a full coin sync from scratch. With about a dozen coins supported it is easy to make a change that slows down parallel sync without knowing about it. With the jenkins I will at least know if the latest versions are as good as the prior ones for sync stability and speed.
Basilisk mode had an issue in some paths, which took a while to track down, but now I have the LP tradebot properly being able to receive the swap request, compare against its list of active pairs and conditionally send back a quote.
Really quite a lot of that process is working now, but it gets stuck on the return path to the original requestor. Strange thing is that it is doing the protocol properly as near as I can tell, but just stops.
So, I had to dig into why it was stuck and after many hours it looks like the OUT/MSG protocol I wrote about yesterday gets stuck after receiving some sequence. Instead of the problem being the DEX protocol, it turned out to be the lower level transport. I didnt see anything immediately wrong, but I think I will switch over to a single serialized request queue instead of using mutex on each thread’s access to the OUT/MSG data store.
Sometimes with things that are mostly working, but not quite, “changing its shape” will evolve it so the issue goes away. And in practice even though there shouldnt be a difference between a parallel set of operations protected by mutex vs parallel request serialized by queue, a lot of times there is. Since the latter is a much more controlled system, it can be viewed as an improvement and if it also happens to make things more robust, all the better.