Mints and markets

I spent way to much time working yesterday. I was trying to get the exchange working, and had some irregularities with certain markets where the token mint wasn’t working properly. I about lost my damn mind.

The Serum web3 library has two files that are relevant, one contains market data such as the name and market ID, and a mint list that maps the symbols to the token mints. It seems that the Serum program is able to query the base and quote currency mints from the market on-chain, and the exchange code then does a reverse lookup to display the names.

But for some reason, our implementation displays UNKNOWN for the bases. So my mission yesterday was to figure this out. And I failed. Problem number one was that my local development system is too unstable to run the DEX via yarn start. It caused my IDE to become very slow, and the entire system would lock up after an hour or so. So I started doing live edits on the EC2 instance where we run the API. This was less than ideal because I was having to edit through an ssh console, and it was very inefficient. Now for starters, yarn isn’t watching the serum dependency where we’re making the changes, so I’d have to restart the app each time, which takes about five or more minutes. I started getting more and more frustrated because it didn’t seem like anything I was doing was having any effect.

It wasn’t.

The original dex code uses @project-serum/serum/ as a dependency. We had been making changes directly within the node-modules version of this to update our mints, but this doesn’t work for source control. So the other dev I’m working with pulled it out into a root folder and included it in package.json using a file: designation. It worked great locally and in the Amplify build — mostly — so I thought all was well. The first problem I noticed was that Amplify had the node-modules cached in the yml build file, and changes in our project path didn’t get updated. So I removed the cache and it was fine. But I missed something on the EC2 instance.

It was looking to the node-module directory during the build process. Now I’m not sure about the internal workings of yarn, but on my local dev instance, restarting yarn picks up changes in the embedded module. Not so on the EC2 instance. So late last night I ripped out the node-module folder and tried to rebuild the app. It didn’t find our local version.

So that’s where I am at this morning. I either need to spin up a new EC2 instance to do this work or rest the password on this old server running under my desk. My VM is just not cutting it for this work. I’ve got several discrepancies between instances of the UI that are running, and I’m not quite sure why. I did spend a good chunk of time yesterday experimenting with different RPC servers and CORS issues, as I wasn’t quite sure whether there were network instability issues or whether I was getting rate limited, but I was having all kinds of failed calls. Serum sends a huge number of RPC calls. A good number of them are orderbook updates, but there are a lot of them that have to do with spl-token accounts.

Solana is one complicated beast.

So now it’s back to work, with an awesome hangover, no less. There’s a Star Atlas town hall later today and I had really wanted to have this thing ready to go for it. I got the card validator all set, but I really to eliminate any crashing bugs before I give out this url.

Leave a Reply

Your email address will not be published. Required fields are marked *