DEV Community: Eugen Taranowski

I gave it four facts and it invented a fifth

Eugen Taranowski — Fri, 21 Aug 2026 18:59:12 +0000

Show data on my TV tracker comes from TMDB, like it does for a great many TV apps. That includes the synopsis — which means the paragraph on my page for a given show is the same paragraph on TMDB itself, on JustWatch, on Trakt, and on every other app built from the same API.

Duplicate text isn't a penalty. It just can't win anything. Those are the pages meant to answer "when is the next episode of X", and the only original thing on them was my own countdown.

So: generate something. I have a machine on the LAN running a 35B model, which is more than enough to write a paragraph. The interesting part turned out to be everything I had to forbid.

The obvious thing to generate is the wrong thing

The instinct is to rewrite the synopsis. Same information, different words, no longer duplicate. I didn't, for two reasons.

The first is that it lands squarely in what Google calls scaled content abuse — generating many pages without adding value. A reworded plot summary is a different arrangement of the same information: high volume, nothing new. Whether or not it trips anything, it's hard to argue you've added something the reader didn't have.

The second is simpler. Nobody searches for a synopsis. People type "is Silo weekly or all at once", "what day does Silo come out", "how many episodes in season 3". A rewritten plot summary matches none of that.

What does match it is release cadence — and cadence isn't a field. Nobody has it, because it has to be derived:

// Modal gap between consecutive episode air dates, not the mean:
// one abnormal break (a strike, a pandemic) drags an average enough
// to describe an annual show as arriving every three years.
const gaps: number[] = [];
for (let i = 1; i < dates.length; i += 1) {
  gaps.push(Math.round(dates[i].diff(dates[i - 1], "days").days));
}
// 7 -> weekly, 1 -> daily, 0 -> all at once

The same trick over season premieres gives "new seasons have arrived roughly every two years", which is genuinely useful and which no other TV site states.

The division of labour

This is the part worth copying, if anything here is: my code derives the facts, and the model is only ever asked to turn them into sentences.

It receives a small JSON object and a rule that everything in the paragraph must come from it:

{
  "name": "House of the Dragon",
  "networks": ["HBO"],
  "status": "Returning Series",
  "cadence": "weekly",
  "releaseWeekday": "Sunday",
  "numberOfSeasons": 3,
  "firstAirYear": 2022
}

If the model supplied the facts too, the failure mode would be confident invention across several hundred pages, on a site whose entire premise is telling people a date accurately. Not a risk worth taking to save writing a function.

Then it invented things anyway

Four failures, in the order I found them. None threw an error. Each would have been published.

It explained an internal flag, backwards. My facts included a boolean recording that TMDB stores this show's dates a day before the network advertises them — a real convention I correct for. Handed that flag, the model wrote:

New episodes are released weekly, typically arriving one day before the scheduled Thursday air date.

Which isn't what the flag means, isn't true, and is meaningless to a reader. I stopped giving it that field. Facts a model can't phrase safely don't belong in its input.

It wrote a date into text meant to last months. One note ended "…with the next installment airing tomorrow." The entire design keeps dates out of the stored text and computes them live on every render, precisely so nothing goes stale — and the model reached for "tomorrow" anyway. My validation rejected months and years. It did not reject relative time.

It described a running show as finished. Given numberOfSeasons: 4 it wrote "has completed four seasons" about a series airing its fourth. That field is how many seasons exist, not how many have ended. An easy thing for a person to misread too — but a person misreads it once, not two hundred times.

And then it made something up. At temperature 0.5:

The third season follows three years after the second.

That sentence appears nowhere in its input. It came from the model's own knowledge of the show, in direct violation of an instruction telling it not to, and it reads exactly like the sentences around it that were true.

What I did about it

Prompt rules for what a rule can fix, and a validator for what it can't:

const RELATIVE_TIME =
  /\b(today|tomorrow|tonight|yesterday|this week|next week|right now)\b/i;

const rejectReason = (body: string, facts: ShowFacts): string | null => {
  // Check everything EXCEPT the show's own name — "The Tonight Show
  // Starring Jimmy Fallon" was rejected for containing "Tonight".
  const withoutTitle = body.replace(titlePattern(facts.name), " ");

  if (MONTHS.test(withoutTitle)) return "names a month";
  const rel = withoutTitle.match(RELATIVE_TIME);
  if (rel) return `relative time ("${rel[0]}")`;
  // ...stray years, spelled-out large numbers
  return null;
};

Rejected output is regenerated, twice, then skipped.

That last check is worth a note on where to stop tuning a prompt. A prompt rule took spelled-out numbers from three notes in twenty down to one, and no further. Past that point another sentence of instruction was worth less than four lines of regex the retry loop enforces. A model can be asked; a check can insist.

Temperature went 0.5 → 0.2 → 0.35. At 0.2 the invention stopped and every note became structurally identical — the same sentence with the values swapped. Once the fact rules were strong enough to carry the discipline themselves, 0.35 bought back sentence variety without the invention returning. I checked that by running the offending show five times, rather than assuming.

The validator had its own bugs, of course

It rejected The Tonight Show Starring Jimmy Fallon for containing "tonight", and Reply 1988 for naming a year. Both were in the show's own title. The fix — strip the title before checking — was already in place for two of the four checks and had simply never been applied to the others.

It also rejected two shows for naming the year they ended, which can never go stale and should always have been allowed. "Aired from 2011 to 2020" is strictly better than trailing off.

Final run: 251 notes, one failure. That one still has no note, because it was rejected twice for a badly formatted number. No note is better than a bad one, and a pipeline that can decline to publish is worth more than one that always produces something.

What I'd take from it

Give a model facts to phrase, not questions to answer. Everything that went wrong was the model reaching past its input — for a fact it knew, for a word that felt natural, for an explanation of something it had been handed but didn't understand.

Whatever you forbid in the prompt, check for in code. Every one of these failures was already forbidden in writing. The rules weren't ignored so much as outweighed by whatever made the sentence read well.

And the thing that made the output useful wasn't the model at all. It was spending an afternoon working out which facts were worth having — cadence, release weekday, the gap between seasons — none of which existed as fields, all of which had to be computed first.

The model wrote the sentences. The value was in what it was given to say.

One line of JavaScript disabled server rendering on 190 pages

Eugen Taranowski — Wed, 19 Aug 2026 18:58:05 +0000

A while ago I did the SEO work properly. Every show page on my TV tracker got a real title and description instead of the site-wide default, an Open Graph image, a sitemap pulling in the shows people actually search for. It took a day. It worked — I checked the pages, the tags were there, the previews rendered.

Months later Google Search Console reported that roughly 190 of those pages were soft 404s: URLs that return a success status but look, to a crawler, like an error page.

The obvious readings were all wrong. The pages returned 200. They weren't empty, duplicated, or thin. Open any of them and you get a show, a poster, a trailer, a cast list, an episode list. By any measure available in a browser, they were fine.

Looking at what was actually sent

The thing I had never done was look at the HTML the server sent, as opposed to the page the browser ended up showing. Those are different documents, and only the first is what a crawler sees first.

curl -s https://watchnext.leyu.studio/info/125988 | sed 's/<[^>]*>//g'

That left one character of body text.

Not a truncated page. Not a slow page. The server was sending an empty shell and the entire visible site was being assembled in the browser afterwards. Everything I had verified existed only after JavaScript ran. To a crawler taking a first look there was nothing on the page at all — which is exactly what a soft 404 means.

The cause

Somewhere in a context provider wrapping the whole app, one line read the window width during render, to pick a short label over a long one:

const isMobile = window.innerWidth < 640;

On the server there is no window. That line throws ReferenceError: window is not defined every single time the page renders on the server.

Here is the part that turns a small mistake into a large one. Next.js does not fail the build, and it does not show an error. It catches the exception, gives up on server rendering that page, and falls back to rendering in the browser. Which works. The user gets the page, slightly later, and nothing anywhere says anything went wrong.

That's a reasonable thing for a framework to do — degrading to a working page beats showing a visitor a stack trace. The cost is that the signal disappears along with the failure.

Why every kind of testing I did missed it

Look at what doesn't catch this:

The build passes — nothing is statically wrong.
TypeScript passes — window.innerWidth is a perfectly well-typed expression.
The dev server is quiet.
Clicking around works — by then you're in the browser, where window exists.
Lighthouse scores fine — it runs JavaScript.
Sharing a link gives a correct preview — metadata comes from a separate server function that never touched the broken code.

Every tool I had was either running JavaScript or checking something orthogonal. The one observer that behaves differently — a crawler forming a first impression from raw HTML — was the one I had no feedback loop from, until Search Console told me months after the fact.

The fix, in two parts

The line itself is easy. Keep the value in state, start at something true on the server, set the real value after mount:

const [isMobile, setIsMobile] = useState(false);

useEffect(() => {
  const sync = () => setIsMobile(window.innerWidth < 640);
  sync();
  window.addEventListener("resize", sync);
  return () => window.removeEventListener("resize", sync);
}, []);

The server renders the desktop label, the browser corrects it immediately if needed, and the first render matches on both sides so there's no hydration mismatch either.

The second part was less obvious. With server rendering restored, the show pages served their layout — but the show data was still fetched in the browser, so the server was sending a page reading "Loading show details…". Technically server-rendered. Still nothing to read.

So the page component became a server component that fetches the show and hands it to the client component as an initial value:

// page.tsx — server component
export default async function Page({ params }) {
  const show = await getShow(params.id);
  return <ShowDetailsClient initialShow={show} />;
}

// ShowDetailsClient.tsx — "use client"
const [show, setShow] = useState(initialShow);
const [isLoading, setIsLoading] = useState(!initialShow);

useEffect(() => {
  if (initialShow) return; // already have it, don't refetch
  // ...client fetch for the navigation case
}, [initialShow]);

The same getShow() is used by generateMetadata and by the page body. Next deduplicates the call, so this costs one request, not two.

After both changes, the measurement that returned one character returned about 1,750, with a real <h1>, the overview, and the genre and description sections — all present before any JavaScript runs.

What to take from it

Touching a browser API during render doesn't fail loudly. It fails by turning off the thing you can't see from a browser. That's the whole lesson, and it generalises past this one property: document, localStorage, navigator, and anything reaching them indirectly through a library.

The practical check takes ten seconds, and I now do it after any change to a page that matters for search:

curl -s https://example.com/some-page | sed 's/<[^>]*>//g'

If the result is a spinner, a loading message, or nothing at all, your page isn't server-rendered regardless of what it looks like in a tab. View-source works just as well. The point is only that you have to look at the document the server sent, because that's the document the crawler judged.

The wider version is worth saying plainly. I wrote the metadata, verified it, and moved on — and the verification happened entirely inside the environment where the bug couldn't appear. The work was real and the checking was real, and neither was worth much, because both happened on the wrong side of the line.

This is the second bug on this site whose root cause was the gap between what the server produces and what the browser ends up with. The other one deleted people's saved shows, and also only showed up on a path developers rarely take.

The bug that only happened if you bookmarked the page

Eugen Taranowski — Mon, 17 Aug 2026 10:31:47 +0000

I found this by accident, while chasing something else entirely. Testing an unrelated date bug, I loaded the Favorites page directly by URL — and the test data I'd just saved was gone. Not "failed to display". Gone from storage.

The strange part: clicking through to the same page from inside the app worked perfectly, every time. Same page, same code, same data. The only difference was how you arrived.

That asymmetry turned out to be the entire explanation.

Two reasonable decisions

The first piece is a hydration fix. The app stores your saved shows in localStorage. The obvious way to load them is to read storage when the state is first created:

const [favorites, setFavorites] = useState(() =>
  JSON.parse(localStorage.getItem("favorites"))
);

That works, until you server-render. The server has no localStorage, so it renders an empty list. A returning visitor's browser does have the data, so it renders a full one. React compares the two, finds they disagree, and complains about a hydration mismatch.

The standard fix — and the one I'd applied earlier — is to stop reading storage during render. Start empty on both server and client so the first render matches, then load the real data in an effect afterwards:

const [favorites, setFavorites] = useState([]);

useEffect(() => {
  const stored = localStorage.getItem("favorites");
  if (stored) setFavorites(JSON.parse(stored));
}, []);

The second piece is ordinary product behaviour: when you open Favorites, if the show data hasn't been refreshed in twelve hours, fetch fresh details for each saved show and store the result.

useEffect(() => {
  if (Date.now() - lastRefresh > TWELVE_HOURS) {
    refreshFavorites(); // maps over `favorites`, writes result to localStorage
  }
}, []);

Both correct. Both, in isolation, uncontroversial.

Where they collide

React runs effects from the bottom of the tree upward. Children first, then their parents.

When you land directly on the Favorites page, the app's data provider and the page itself mount together, in the same commit. So:

The page's effect runs first. It checks the timestamp, decides a refresh is due, and calls the refresh function.
That function reads the current list of favorites — which, at this exact moment, is still the empty array everything started as, because the provider's effect (a parent effect) hasn't run yet.
So it refreshes a list of zero shows. It receives zero shows back. It writes that result to localStorage, overwriting whatever was there.
A moment later the provider's effect runs, reads storage to restore your favorites, and finds an empty array. Because it just was one.

The hydration fix wasn't the mistake — it was the right call, and reverting it would just bring back the bug it solved. The mistake was not noticing that deferring the load created a window where the data legitimately isn't there yet, and that something else was already running inside that window.

Why normal use never showed it

Navigate to Favorites by clicking a link and the provider is already mounted from whatever page you were on. Its effect ran long ago. The favorites are loaded. The page mounts alone, the refresh reads a populated list, and everything works.

The bug needs the provider and the page to mount in the same commit, which only happens on a fresh load of that specific URL: a bookmark, a refresh while sitting on the page, a link shared from outside, or reopening a tab.

Which is a genuinely unpleasant profile for a data-loss bug. It skips the path developers use constantly while building — clicking around a running app — and hits the path a returning user is most likely to take. Someone who bookmarks the page they care about is exactly the person with the most to lose.

The fix, and a better one from the comments

My first fix was a flag distinguishing "empty" from "not loaded yet":

const [hydrated, setHydrated] = useState(false);

useEffect(() => {
  try {
    const stored = localStorage.getItem("favorites");
    if (stored) setFavorites(JSON.parse(stored));
  } finally {
    setHydrated(true); // runs even if the parse throws
  }
}, []);

with the page waiting on it before refreshing.

That works. But when I posted this, a commenter pointed out it's weaker than it looks: it's a guard every future caller has to remember to check — structurally the same shape as the original bug, correct only as long as nobody forgets.

The stronger version: make the refresh read storage directly rather than trusting React state.

const refreshFavorites = useCallback(async () => {
  const raw = localStorage.getItem("favorites");
  const saved = raw ? JSON.parse(raw) : [];
  if (saved.length === 0) return;
  // ...refresh `saved`, write the result back
}, []); // no dependency on component state at all

Now there is no ordering in which the refresh can observe fewer items than are actually saved. The overwrite isn't guarded against — it's impossible. I removed the flag from the write path entirely and re-tested the original failure scenario with the guard gone, to confirm the safety was structural rather than conditional.

The same commenter made a second point I'd missed: the empty state was rendering "No favorites added yet" during that same pre-hydration window — telling a returning user their list was gone, a moment before it appeared. "Empty" and "not loaded yet" have to be distinguishable when you render, too, not just when you write.

What I'd take from it

Deferring work to fix one problem creates a window where your state is temporarily untrue. That's fine, as long as nothing else acts during it. Worth asking, whenever you move initialisation into an effect: what else runs before this, and what will it think the state means?

More generally: "empty" and "not loaded yet" looking identical is a recurring source of this kind of damage. If code can act on the difference, it needs to be able to see the difference.

And the reason I found it at all is that I loaded a page the way a user would, rather than the way I always did.

Why TMDB says your Apple TV+ show airs a day early

Eugen Taranowski — Mon, 17 Aug 2026 10:22:43 +0000

A user reported that my TV tracker was showing the wrong air date for Silo. Their favourites card said the next episode aired today. Google said tomorrow. One of us was wrong, and the obvious assumption was that it was me.

It was — but not for the reason I first thought, and the underlying cause is worth writing down, because it affects any app built on the same data.

First, a genuine bug of my own

The initial report was that the same episode showed different countdowns in different places in the app: a show card said "airs tomorrow" while the notification for the same episode said "airs today".

That one was mine. Two different pieces of code were deciding what "today" meant in two different ways. One compared calendar days entirely within the show's own country's timezone. The other took the show's end-of-day cutoff, converted that instant into the viewer's local timezone, and compared calendar days there.

Those two approaches agree only when the show's timezone and the viewer's are close together. For a US show viewed from Germany — a nine-hour gap — they routinely land on different calendar days, shifting the whole today/tomorrow boundary depending on what time of day you happened to look.

I fixed it by making both read from one shared function that only ever counts days in a single timezone. The two displays then agreed with each other perfectly.

They were also both still wrong.

The part that wasn't my code

With the app now internally consistent, Silo still said "airs today" for an episode that Apple, and everyone reporting on it, placed the following day. So I checked the source data against published release dates.

Like a great many TV apps, this one gets show data from TMDB. Here's what its air_date field said for two consecutive Silo episodes, next to the dates in press coverage:

Episode	TMDB	Actually released
S3E6 "The Drive"	Thu 6 Aug	Fri 7 Aug
S3E7 "Radio"	Thu 13 Aug	Fri 14 Aug

Both exactly one day early. Both a Thursday where the real release was a Friday — matching Silo's actual weekly Friday schedule. Two consecutive episodes ruled out a one-off typo.

Why the date is "wrong" on purpose

It isn't a typo. TMDB's convention is that air_date records the earliest calendar day an episode becomes available in its country of origin — not the date the platform advertises.

For a traditional broadcaster those are the same day. For a global streaming service they aren't. A TMDB moderator spells it out in their "Clarification on Air Date policy" thread:

"Amazon Prime release its new content at 0h GMT and Apple TV at 0h Ireland Time on the advertized date, which means that the content is available in the evening of the previous day in the United States. If its a United States show, the recorded date is this previous day and if its an European show, the recorded date is the advertize day."

That last sentence is the part worth reading twice, and the part I initially got wrong.

The shift is not a property of the service. It depends on the show's origin country: midnight in Ireland is still the previous evening in Los Angeles, but it's simply midnight in London. So a British show on Apple TV+ is recorded under its advertised date, with no gap at all.

I checked, because my first version of the fix ignored that clause. Slow Horses is a British series on Apple TV+: TMDB says 29 October, and so does the press. Shifting that one — as my first attempt would have — would have made it a day late. The same bug pointing the other way.

A control case, because one pattern isn't a rule

The obvious risk here is over-correcting: deciding "TMDB is a day early" and shifting everything, which breaks every show that was already right.

So I checked a show releasing the same week on a different service: Stuart Fails to Save the Universe, on HBO Max. TMDB said 13 August. Press said 13 August. No gap.

The discrepancy isn't general to TMDB, or to streaming, or even to every show on these services. It needs both conditions at once: a service that releases globally at a single instant, and an origin country far enough west that the instant lands on the previous local day.

A reader's example, and the detail that explains it

After this went up, a commenter pointed out the same thing with the Ted Lasso season four premiere — a cleaner example than mine, because the advertised date comes from Apple directly.

TMDB has the episode on 4 August. Apple's own press release says the season returns Wednesday 5 August. It went live at 9pm Eastern on the 4th — the night before the date Apple itself advertised.

The same commenter mentioned something that turns out to be the root of the whole problem: TMDB records a date, with no time attached.

That's why this can't be resolved inside TMDB. "4 August" is a complete answer if you also know the release happened at 9pm Eastern; it's ambiguous if you don't. A timestamp would let every consumer convert correctly for its own audience. A bare date forces each of them to reconstruct the missing hours — which is exactly the reconstruction this post is about.

What I actually did

The app now reads a show's network and its origin country together. The date is shifted forward to the advertised release only when the service is one of these two and the origin country sits behind Irish time — decided by comparing the two timezones, rather than by keeping a list of countries.

Concretely: Silo (American) shifts. Slow Horses (British) doesn't, despite both being Apple TV+ originals released the same way.

If you build on TMDB

Three things worth taking away.

air_date means "earliest availability in the origin country", not "the date this is advertised as". Most of the time there's no difference. For globally-released streaming shows there is, and it will look like your app is broken.

The correction is narrower than it first appears. It would have been easy — and wrong — to shift everything on those two services. Half the fix is knowing when not to apply it.

Agreement isn't correctness. I fixed a real inconsistency in my own code, the two displays started agreeing with each other, and that felt like success. It was only checking against the outside world — the thing the user did, and I hadn't — that surfaced the actual problem. Then I repeated the mistake in miniature by shipping a network-only rule without checking a British show against it.