Caught the Same Kind of Bug Again, So This Time I Closed Off the Whole Class

Found another case of a major ticker's name slipping through recognition — this time, instead of just patching it, I restructured things so this class of bug can't come back

Yesterday's devlog covered a bug where the most important ticker was falling out of results because of a name-recognition failure. Today there was another case of the same thing. This time the response was different.

Instead of fixing it, I made sure it can't happen again

I noticed that news for one large-cap ticker was barely showing up at all. The cause: a common abbreviation for that ticker wasn't registered in the recognition list.

Different specific bug from yesterday's, but the exact same pattern.

Seeing the same class of bug repeat for what felt like the umpteenth time, I decided not to just patch it and move on. The name/abbreviation recognition logic was scattered across several places in the project, each implemented separately.

Fixing one spot left the others stale — which is exactly how this bug had leaked through in the first place.

So I pulled the logic out into a single shared module that every relevant part of the project now imports. There's exactly one place left to update the recognition list.

After the change, I diffed all existing outputs against the old behavior to make sure nothing shifted, and they matched exactly.

I also fixed a related issue where one company's abbreviation was accidentally swallowing a different company's name. A large holding company's short name happened to be a substring of one of its subsidiaries' names, which mixed up news between the two. I added it to an exception list to split them apart.

Started a new side project

Up to now I'd only been using news as a sentiment signal. It occurred to me that stock discussion board data could be another useful signal for retail sentiment, so I started collecting it separately.

I applied the same principles as the news archive. Board posts are a decaying kind of data too — view counts and reaction counts keep changing over time — so I record both the post time and the collection time, so it can be sliced accurately as-of any point later.

I decided not to feed this signal into the actual analysis yet, though. There's an important comparison experiment already running, and mixing in a new signal now could contaminate it.

So for now I'm just collecting and holding off on using it. The data decays, so collect it now; the decision isn't urgent, so make it later.

Also this week

• Went through the live-trading safety layer again. Found a gap in how the system handles a request that never gets a response at all and ends ambiguously — planned out a sequence of fixes for that.
• Retired an experimental intraday response feature that had been running for a while. Not because the direction was wrong, but because there was no way to actually measure whether it worked. It's an admission that the current tooling can't judge it either way, not that the idea itself was bad.

Overnight, the automated analysis ran into a fairly serious problem, and it took another full day to track down the cause. More on that in the next devlog.