DEV Community: Eugen Taranowski

Almost every crawl error on our domain came from a site that didn't exist yet

Eugen Taranowski — Mon, 14 Sep 2026 06:55:07 +0000

Originally published on the WatchNext blog.

Google had crawled WatchNext and indexed none of it. The coverage report listed 11 pages as crawled, currently not indexed and 200 as discovered, currently not indexed — found, but never fetched.

The crawl stats report had what looked like the reason. Of 453 crawl requests over the month, 17% had ended in a DNS error. If Google couldn't reliably resolve the site, it would hardly be surprising that it wasn't indexing it.

None of those errors were WatchNext's.

The report was about four sites

WatchNext lives at watchnext.leyu.studio. Search Console had been set up as a domain property for leyu.studio, which is the convenient choice: one verification covers every subdomain. It also means every number in the report is the sum of every subdomain, with nothing on the overview telling you so.

The hosts table, further down the same report, splits it out:

Host	Crawl requests
`shop.leyu.studio`	234
`watchnext.leyu.studio`	134
`leyu.studio`	77
`checkout.leyu.studio`	8

An online shop, its checkout, this app, and the bare domain. The "WatchNext crawl report" was a report on four sites, of which WatchNext was a little under a third.

The site that didn't exist

Look at the third row. leyu.studio itself had nothing on it — no page, no server, and critically no DNS address record. The subdomains all pointed somewhere; the bare domain pointed nowhere, and its www variant didn't exist at all.

Google had still made 77 requests to it. And the DNS error rate, 17.00% of 453, is 77 requests. Almost every failure in the report — 77 of the 81 failed requests, with the other four being ordinary 404s — was Google repeatedly trying to reach a site that had never been built.

That match is worth trusting, and the reason is not that the numbers are equal. It's that there is a mechanism which forces them to be. A hostname with no address record cannot get past DNS, so every one of its requests has to fail at exactly that stage and no other. The count is the consequence of the cause.

The daily chart is consistent with it, too. On each of the last five days of the export, every request recorded no bytes downloaded and a response time of zero — which is what a request looks like when there was never a server to talk to.

One thing we can't explain: the same hosts table lists all four hosts with a status of "No problems", including the one that couldn't resolve. Whatever that column checks, it evidently isn't the fate of individual requests, so we didn't lean on it.

The match that meant nothing

Here is the part worth writing down, because it very nearly went into the diagnosis as a finding.

The crawl report also breaks requests down by file type, and 8.17% of them were HTML. WatchNext received 134 requests. Multiply one by the other and you get almost exactly 11 page fetches — and the coverage report said exactly 11 pages had been crawled and not indexed.

That is a beautiful result. Google had fetched precisely the 11 pages it then declined to index, and never got round to the other 200. It explains the coverage report completely.

It is also not a result at all. The 8.17% is the HTML share across all four hosts combined. Applying it to WatchNext alone assumes a Next.js app and a Shopify storefront request the same mix of JavaScript, images, stylesheets and pages — and there is no reason on earth they would. The multiplication borrows a ratio from a population it doesn't describe, and the tidy answer it produces is a coincidence.

So two numbers matched perfectly in the same investigation, one after the other, and only one of the matches meant anything. The difference between them is the difference between a count that a cause forces and a count that arithmetic happens to land on.

What was actually going on with WatchNext

With the apex's errors set aside, the rest of the report is quieter and more useful. 99.56% of crawl requests were refreshes of URLs Google already knew about; 0.44% were discovery. Google was barely looking for anything new.

It is tempting to add that the busiest day of crawling — 113 requests on 14 August — came three days before we committed the fix that gave these pages server-rendered content, so Google's opinion of the site would have been formed on the broken version. But that chart is for the whole property too, and it doesn't say which host those 113 requests went to. It's the same trap as the HTML share, one section later.

The evidence that does hold up is narrower. Inspecting a single post showed Google had found it through a link from another site, crawled it on 20 August — after the fix — fetched it successfully, and read the canonical URL we had declared. And it still hadn't indexed it. Nothing in that is a technical fault. It points at a young domain that Google has no particular reason to trust yet, which no DNS record will change.

What we did about it

We built something at leyu.studio, so the bare domain now resolves to a real page instead of nothing, and www redirects to it. We also added a separate URL-prefix property for each site, so WatchNext's report is only about WatchNext.

It is worth being plain about what that fixes. It removes the noise: the property should stop reporting a failure rate that was never about the app. It does not, by itself, get a single WatchNext page indexed. Those were never the same problem — they only looked like one because they were summed into the same number.

The general version

When two numbers from different places match exactly, it feels like confirmation, and it is very hard to argue with. Two questions separate the matches that mean something from the ones that don't.

Is there a mechanism that forces them to be equal? A hostname with no address can only fail at DNS, so its request count and its DNS failure count must agree. Nothing forces an 8% share to produce exactly the right number of page fetches; it just did.

Does the ratio describe the thing you applied it to? A percentage is a statement about a population. Apply it to a subset with a different make-up and it will still return a number — precise, plausible and wrong.

The new site went up on 12 September. Search Console's reports take weeks to reflect a change like this, so we don't yet know what the numbers look like afterwards — and given the rest of this post, we're not going to guess. We'll add them here when they exist.

WatchNext is a deliberately simple TV tracker: it tells you when the next episode of your favourite shows airs, for any show, in any country — and nothing else.

Three things change when you put Cloudflare in front of your host

Eugen Taranowski — Sat, 12 Sep 2026 16:39:40 +0000

Originally published on the WatchNext blog.

WatchNext's DNS lives on Cloudflare with the proxy enabled, in front of Netlify. That arrangement is extremely common and almost entirely uneventful: requests get faster, the origin gets shielded, and nothing appears to change.

Nothing appears to. Three things did, and none of them failed loudly enough to notice on its own.

1. Your host's country header starts describing your datacenter

WatchNext uses a visitor's country for a small set of defaults: which streaming services to show beside a title, which age rating to display, and — if you ask for it — which shows were made where you live. None of that touches air dates, which always follow the show's own country. But get the visitor's country wrong and all three quietly point somewhere else.

That used to be a browser-side call to a third-party IP geolocation service. Which meant every visitor's IP address was handed to an undisclosed company on their first page load, before any consent, and the app inherited that service's rate limits and downtime. The request already arrives at our own infrastructure, and hosts attach the country they resolved at the edge, so the answer was available for free with no extra party involved.

Every platform spells it differently — Netlify sends x-nf-geo as base64-encoded JSON, Vercel sends x-vercel-ip-country, Cloudflare sends cf-ipcountry — so the sensible thing is to read whichever is present.

Here is the part that matters once a proxy is in front. Your origin no longer receives connections from visitors. It receives them from Cloudflare. So the header your host generates describes the machine that relayed the request — a datacenter — rather than the person who made it.

const country =
  h.get("cf-ipcountry") ??                 // Cloudflare (proxied)
  readNetlifyGeo(h.get("x-nf-geo")) ??     // Netlify
  h.get("x-vercel-ip-country") ??          // Vercel
  h.get("x-country") ??                    // other proxies / self-hosted
  null;

Cloudflare first, deliberately. cf-ipcountry only exists when Cloudflare is actually proxying, and when it exists it is the only header in that list still describing the visitor. When Cloudflare isn't in front, it is simply absent and the host's own value is correct again.

The reason this is worth a section rather than a footnote is the failure mode. A geolocation lookup reading the wrong header does not throw, log anything, or return an obviously bogus value. It returns a real, well-formed country code — just the datacenter's. Our requests have come through Amsterdam and Munich on different days. For a largely European audience, "Netherlands" and "Germany" are answers plausible enough to survive a casual look at the page.

Two more Cloudflare values worth handling: XX when it can't determine a country, and T1 for traffic arriving over Tor. Both are two ASCII letters, so both sail through a naive /^[A-Za-z]{2}$/ check and become a "country" your lookups will never match.

2. Responses start coming from a layer you didn't configure

After the proxy goes on, every response says this:

server: cloudflare

Which tells you almost nothing. It identifies who handed the response over, not who produced it. The useful signal is whether your host's fingerprint is still on it — on Netlify that is x-nf-request-id.

We found this while looking at something trivial: a www-to-apex redirect on the studio site next door. It reported server: cloudflare, and also carried an x-nf-request-id. Both at once, which is the tell — Netlify generated that redirect and Cloudflare merely relayed it. The request had travelled all the way to the origin to be told to go somewhere else.

Arriving over plain HTTP cost two of those round trips: one to upgrade to HTTPS, another to drop the www. Moving the rule into Cloudflare's own redirect rules, so it is answered at the edge, collapsed it:

Request	Before	After
`http://www`	2 hops, both from the origin	1 hop, from the edge
`https://www`	1 hop, from the origin	1 hop, from the edge

Afterwards the 301 still says server: cloudflare — but no longer carries x-nf-request-id, which is how you know the rule is really being served at the edge rather than quietly passing through.

The same question is worth asking about headers. WatchNext's security headers are declared by the application and emitted by its runtime, and you can see that from the outside: they arrive on responses that carry the host's request id. When a header you've configured somewhere isn't appearing, "which layer is supposed to be adding this, and did the response even come from there?" is usually a faster question than re-reading the config.

3. Your privacy policy has a processor it doesn't name

This is the one we got wrong for a while, and it is the reason this post exists.

Our privacy policy named our host. It did not name Cloudflare. But once the proxy is on, every single request reaches Cloudflare before it reaches the host — so Cloudflare processes every visitor's IP address, user agent and requested URL. And, per the section above, we actively depend on it doing so: the country behind those streaming services, ratings and local shows is a value Cloudflare computed.

That is not a technicality about a CDN. In the arrangement we had, the party doing the most visible processing of visitor data was the one the policy didn't mention. So Cloudflare went into all four places that enumerate who touches the data: the usage-data description, the list of service providers, the international-transfers section, and the third-party policy links.

One addition mattered more than the rest. Cloudflare may set a strictly necessary security cookie when it sees suspicious traffic. Our cookie section claims to enumerate everything that gets stored on your device — so leaving that out didn't merely omit something, it made a statement we were publishing inaccurate.

Nothing here is legal advice, and the specific obligations differ by jurisdiction — check yours. The engineering point is the transferable one: adding a proxy adds an organisation that processes your visitors' personal data. That makes it a documentation change as much as an infrastructure change, and the documentation is the half that has no deploy step to remind you.

The pattern underneath all three

A proxy is not a transparent pipe. It terminates TLS, it can answer requests without consulting your origin at all, it changes what your origin is able to see about the client, and it handles personal data on the way through.

Every one of those is genuinely useful — that is what you turned it on for. But each has a consequence you have to go looking for, because the symptom of getting it wrong is never an error. It is a page that loads faster while quietly telling someone in Vietnam what airs tonight in Amsterdam.

Two questions catch most of it. Who actually answered this response? — check for your host's fingerprint rather than trusting the server header. And what did each layer see? — because anything that sees a visitor's IP address is a party you are relying on, whether or not you have written it down.

We had both answers available the whole time, in response headers anyone can read with curl -I. We just hadn't thought to ask until a redirect looked one hop too long.

Correction, 14 September 2026: an earlier version of this post said WatchNext uses the visitor's country to localise air dates. It doesn't. Dates always follow the show's own country; the visitor's country only sets default streaming services, age ratings and the local-shows filter. A reader's question about VPNs prompted the recheck.

WatchNext is a deliberately simple TV tracker: it tells you when the next episode of your favourite shows airs, for any show, in any country — and nothing else.

The test that failed every morning and passed every afternoon

Eugen Taranowski — Sat, 12 Sep 2026 16:13:57 +0000

Originally published on the WatchNext blog.

While making an unrelated change — adding a processor to a privacy page and a link to a footer — the test suite came back with eleven passes and one failure:

- 1
+ 2

 ❯ tests/airDate.test.ts:125:47
    125|     expect(getAirDateDaysDiff(plus(1), "US")).toBe(1);
       |                                               ^

An episode airing tomorrow was being counted as two days away. That is about as load-bearing as a bug gets in an app whose entire purpose is telling you when the next episode airs.

It turned out the countdown was fine. The test was wrong, in a way that made it fail for roughly a third of every day and pass for the rest.

First: prove it isn't your change

The edited files were a privacy page, a footer and a markdown document. The failing test covers air-date arithmetic. Those are obviously unrelated — but "obviously unrelated" is a hypothesis, and the cost of checking it is one command:

git stash && npx vitest run   # same failure
git stash pop

Identical failure with the changes removed. That single result reframes everything that follows: this is not a regression being debugged, it is an existing defect being discovered. Without it, the natural next move is to start reading your own diff for a cause that was never in it — and the worst outcome of that search is "fixing" code of your own that was correct.

Then: rule out the machine

A test about day counting failing intermittently points at timezones, so the first suspect is the machine's own zone. That is easy to test by simply telling the process it lives somewhere else:

TZ=Europe/Dublin     npx vitest run   # 1 failed
TZ=America/New_York  npx vitest run   # 1 failed

Both fail, identically. That is a useful negative: the host timezone changes what the process calls local time, but it does not change the instant at which the test runs. So the hidden dependency is not where the test runs. It is when.

Two calendars, one comparison

Here is the test as written. It builds "tomorrow" and "yesterday" by adding and subtracting a day in milliseconds, then trimming the result to a date:

const today = new Date();
const iso = (d: Date) => d.toISOString().slice(0, 10);
const plus = (n: number) => iso(new Date(today.getTime() + n * 86400000));

expect(getAirDateDaysDiff(plus(1), "US")).toBe(1);
expect(getAirDateDaysDiff(plus(-1), "US")).toBe(-1);

That looks unimpeachable, and it contains the whole bug. toISOString() always formats in UTC. So the date handed to the function is "tomorrow according to UTC".

The function, though, deliberately does not count days in UTC. It counts them in the show's own country's timezone, and for a US show that means America/Los_Angeles. That choice is not an accident or an oversight — it is the fix for an earlier bug where a show's card and its notification disagreed about whether the same episode aired today or tomorrow, because one of them mixed the viewer's timezone into the comparison.

So the test measures from one calendar and the function measures from another. For most of the day they agree. For the hours when UTC has already rolled over to a new date and Los Angeles has not, they do not:

Moment	Test asks about	Function's today	Result
15:00 UTC, 11 Sept	12 Sept	11 Sept (LA)	1 ✓
06:39 UTC, 12 Sept	13 Sept	11 Sept (LA)	2 ✗

At 06:39 UTC on 12 September it is still 23:39 on 11 September in Los Angeles. UTC's "tomorrow" is 13 September. Los Angeles's "today" is the 11th. Two days apart, and the assertion wanted one.

Which means it fails on a timetable

The failure window is exactly the offset between the two zones: seven hours while Los Angeles is on daylight time, eight hours when it isn't. Midnight UTC to around 07:00 UTC, every single day. After that it goes green again on its own.

Two things about that are worse than an ordinary broken test. The first is that it presents as a feature bug — the assertion says an episode airing tomorrow is being counted as two days out, which is precisely what a real off-by-one in the countdown would look like. The second is that re-running it later makes it pass, which quietly teaches everyone that it is "flaky" and can be re-run rather than read.

The fix, and what it deliberately doesn't cover

The repair is to build the fixture in the same frame the function measures in, rather than in UTC:

const zone = timeZoneData.find((e) => e.iso_3166_1 === "US")?.ianaTimeZone;
const plus = (n: number) =>
  DateTime.now().setZone(zone).plus({ days: n }).toISODate() as string;

The zone is looked up from the same table the application uses, so the test does not hardcode a mapping that could later drift out of step with the code.

That has a real cost worth naming: because the fixture now derives its zone from the same table as the code under test, this test can no longer catch a wrong entry in that table. It is not trying to. Its job is the day arithmetic, and covering the mapping is a different test with fixed, hand-written dates. A test that quietly tests two things is how you end up with one that fails for reasons its name doesn't explain.

Checking the fix didn't just silence it

The easiest way to make a failing test pass is to adjust it until it agrees with whatever the code currently does. That is not a fix; it is a deletion with extra steps. So the fixed test was checked the same way the original air-date work was — by breaking the code on purpose and confirming the test notices.

The mutation was to reintroduce exactly the bug this block of tests is named after, replacing the zone-aware "now" with a plain local one:

- const now = zone ? DateTime.now().setZone(zone) : DateTime.now();
+ const now = DateTime.now();

Red again, as it should be. The test still guards the thing it was written to guard; it simply no longer reports a failure that depends on what time you asked.

The general version

Any test that calls new Date() has an input that isn't written down anywhere in it. Most of the time that input is harmless. It stops being harmless the moment the code under test cares about which calendar it is using — and if you are dealing with schedules, billing periods, delivery estimates or anything else with a day boundary in it, your code cares.

There are two honest ways out. Freeze the clock, so "now" is a fixed value you chose. Or, as here, build your fixtures in the same timezone the code measures in, so there is only one calendar in the comparison.

What does not work is the thing that feels most neutral: reaching for UTC in a test because UTC feels like the absence of a timezone. It isn't. In a codebase that reasons in a show's local calendar, UTC is simply a third timezone that nobody asked for — and it will agree with the right answer often enough, and for long enough, to get committed.

After this went up: a reader pushed on the caveat

The note above admits that the repaired test can no longer catch a wrong entry in the timezone table, because it now reads that table itself. A reader asked the obvious follow-up: is anything pinned outside that frame, so the two calendars can still disagree on purpose?

They also supplied a better description of the problem than the one in this post's title — a test with a schedule is not flaky, it is deterministic and on a timer — along with the observation that a retry policy hides exactly that, forever.

The honest answer was "partly, and by accident", which is worth showing as a measurement rather than an opinion. Pointing US at Europe/Berlin fails three other tests, because the day-shift logic compares the origin's offset against Dublin and Berlin is not behind it. But pointing it at America/New_York — still behind Dublin, still entirely plausible — failed nothing at all. The mapping was pinned only insofar as a zone sits east or west of Ireland.

Three things are pinned now.

A frozen instant, which was the reader's suggestion, with one correction to it. The obvious choice of a small-hours UTC time does not discriminate: at 02:00 or 03:00 UTC, Los Angeles and New York are still on the same calendar day and agree on every answer here. 06:00 UTC is where they split — 23:00 on the 11th in Los Angeles, 02:00 on the 12th in New York.

vi.setSystemTime(new Date("2026-09-12T06:00:00Z"));

// In Los Angeles it is still the 11th, so the 12th is tomorrow.
expect(getAirDateDaysDiff("2026-09-12", "US")).toBe(1);
expect(getAirDateDaysDiff("2026-09-13", "US")).toBe(2);

Both halves hardcoded, nothing read from the table. The America/New_York drift now fails this test, and only this test.

The daylight-saving boundary — where checking the claim turned up that we had been wrong about our own code. The assumption was that Math.round was what kept day counting correct across a 23-hour day. It isn't: Luxon's difference between two startOf("day") values is calendar arithmetic, so the transition was already handled and the rounding was doing nothing. Worth pinning anyway, because the obvious simplification does break — a plain millisecond difference across Los Angeles's spring-forward is 0.9583, which floors to zero. An episode airing tomorrow, reported as airing today, one day a year, in one timezone.

A boundary case better than a frozen instant. Côte d'Ivoire sits at UTC+0 all year and observes no daylight saving. Ireland does. So the same origin country is behind the release zone during Irish summer time and exactly level with it in winter — and the shift correctly applies in one case and not the other. That pair cannot be satisfied by a hardcoded list of "western" origin countries, whichever way the list is written, and it puts the Dublin transition itself under test, since that is the thing that moves the answer.

The last part of the question was whether CI runs the suite inside the failure window. It wasn't running the suite at all — there was no test job, only a nightly data-refresh workflow, which is a large part of how a test that failed for seven hours a day survived as long as it did. There is one now, and it deliberately does not pin a timezone: these tests are supposed to hold wherever and whenever they run, and forcing a zone would hide the exact class of bug they exist to catch.

WatchNext is a deliberately simple TV tracker: it tells you when the next episode of your favourite shows airs, for any show, in any country — and nothing else.

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.