DEV Community: Eugen Taranowski

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.