The feature we deleted could never have run in the first place
Eight hundred and nineteen lines removed, a vendor retired, and a migration that refuses to run if its own premise turns out to be wrong.
The Sauce had a stock ticker. It scrolled along showing market movements, it looked good, and nobody ever used it to sell anything.
On 2026-08-14 it was deleted, along with the market-data vendor behind it. Sixteen files, 819 lines removed against 174 added, and about half of what was added is the database migration that cleans up after it.
Deleting a feature is usually the easy part. This one was interesting because of what we found while pulling the thread.
A branch that could not fire
The vendor did not just power the ticker. It also fed an earnings-date lookup inside the deep research feature, which builds a dossier on an account before you call them.
That lookup sat behind a condition: if this account has a stock symbol, go and find its next earnings date. Reasonable. Useful, even, if you sell to public companies.
Nothing has ever written a stock symbol to an account. The function that would have looked one up from a company name had no callers anywhere in the codebase. So the condition was never true, the branch never executed, and the research dossier has always been built from regulatory filings, news, and the user's own signals.
We were about to carefully preserve a feature that had never once run.
The obvious follow-up question is whether to rebuild it properly, and the answer in the commit is no, with a reason worth repeating. Earnings dates are facts, and they come from a market-data API. Asking a language model for one returns a confident guess, and a fabricated earnings date is worse than no earnings date at all, because a seller carries it into a call and says it out loud to somebody who knows better.
There is a general rule in there about where models belong. A model is good at "summarise what this filing means for my pitch" and catastrophic at "when is the next one." Both look like research. Only one of them has a right answer that somebody in the meeting will know.
The migration that argues with itself
The cleanup migration drops the ticker table and two orphaned columns, and it does something I have not seen often enough.
Before dropping anything, it counts the rows and logs the number. Then it checks whether the account symbol column contains any values, and if it does, it raises an error and stops the deploy.
The logic is this: the entire justification for dropping that column is that nothing in the codebase could ever have written to it. If it turns out to hold data, that premise is false. Something wrote it, we do not know what, and the correct response to a destructive migration whose reasoning has just been disproved is to refuse to run and make a human look.
It was verified in three states: against production, against a clean re-run, and against a deliberately populated database, where it correctly refused.
A destructive migration should be able to state the belief that makes it safe, and check it. Most of them just assert the belief in a comment and then do the destruction anyway.
The other half of that evening replaced the prediction-market feed. The old source was a play-money market. The new one is a real-money one.
The argument is one sentence and it is the correct one: a prediction market is only a signal to a seller if somebody is actually risking something on it. A play-money market measures what a self-selected group of people enjoy believing. A real-money market measures what they will pay to be right about. Only the second is information.
Swapping the vendor turned out to involve three separate ways to silently end up with an empty feed, and they are a nice catalogue of how data integrations really break.
The new provider returns the possible outcomes and their prices as strings containing JSON, rather than as arrays. So code that treats them as lists gets the opening bracket character as the first outcome and then fails trying to convert a bracket into a number. Every row would drop and the widget would simply go quiet.
There is no link field, so the URL has to be assembled from the parent event's identifier.
And the rate limit is roughly a twelfth of the old provider's, which turns the polite-request delay from a courtesy into a load-bearing part of the integration. The gap between requests went up by a factor of seven.
Each of those, on its own, produces the same visible symptom: a feed with nothing in it and no error anywhere.
Two things that only broke in combination
The scope of this work was corrected twice by reality, and both corrections are instructive.
The original plan had bundled the ticker removal into an unrelated piece of work about which model answers a prompt. That was split out on the grounds that fifteen files of user interface have nothing to do with model routing. The document doing the splitting also flags that the inherited plan contained a straightforward error: it said to delete the vendor module, and the vendor module fed three features rather than one, so following it literally would have silently killed two things nobody had asked to remove.
Then, ten minutes after the ticker deletion shipped, continuous integration caught something a local run had not. A test file lives in the tests directory rather than the static tests subdirectory, despite a name that implies otherwise, so running only that subdirectory never collected it. The post-mortem in the fix is the useful part: running the entire suite with no database at all is a thirty-five second gate that would have caught it, because the database tests skip and every file-scanning test still runs.
And twenty-two minutes after that, a numbering collision. Another branch had landed a migration with the same number and a different filename. Git merged both files cleanly, because the names differ. The migration runner rejects duplicate numbers outright, and it runs before the server binds its port, so the deploy would have died on the way up.
Neither branch could have caught it alone. Each passed its own tests. It existed only in the combination, which is the failure mode that no amount of care on a single branch will ever find.
The same thing happened again an hour later, with a different pair of numbers.
— DealArena Team