Have you ever thought you had everything under control, only to find out that a bunch of stuff isn’t working for no apparent reason?

Well, that just happened to LightNovels.today.

So, as a final preparation for the 0.8 release, I decided to split up what was left of the monorepo into separate repositories. Due to some problematic decisions, the monorepo was bloating up to 14 gigs, so I thought I’d just split stuff out and it would be easy…

So, obviously the first issue was that the Go code didn’t want to compile anymore. When all the code was in the same repo, it was easy to reference the two shared packages, but now they were trying to refer to a private repo. I tried using workspaces, but that wasn’t working. I ended up moving the shared packages into a public repo, which fixed that. Bit annoyed at myself for how long I spent trying to get workspaces to solve my problem.

Then I deployed to production, and the library page was broken. How was it broken?

Ok, sure I should have sat down and converted the code to the new SearchFilters component, but I didn’t think I needed to. Whatever, I could just fix it up real quick. That went ok, but I was still running into weird issues.

Turns out, I had forgotten to copy a very important file over to the new ln_data repo, known.json. What’s the file do? It’s only the single point of truth for series and volume ids. Without it, the deploy process would just create new ids for everything, which would break the library page, along with a few other things. But not everything, because of some quirks.

The Library page broke because it couldn’t locate the recorded series or volumes. The Add Volume/Series dialogs would also break when the skip series/volume params were set with invalid ids.

At the same time, hardcoded ids that lookup up against the cdn would sort of work. They would return data, but not the most up to date data. But not every series changed, so it wasn’t immediately obvious. Also, any page that was only interacted with dynamically fetched ids would be fine. Unless they were using the lookup data, which needed a full refresh of the page.

This was not helped by my local dev environment containing a mix of old and new ids, depending on the service. That was very unhelpful when trying to reproduce the issue, instead I thought I had even more issues.

In the end, by the time I realized what was going on, I had already fixed most of the issues. Plus I had finally stabilized the child/parent relationships between series. Previously, the list of child series for a series would reorder itself randomly. Now it will keep the order I place it in! I didn’t want to reorder the old child data, so that’s why I didn’t try to restore the old ids.

In the end, I’ve fixed several todo’s and improved the resiliency of the code. Wish I didn’t have to, but sometimes that how things go.