DEV Community: ushiro

A Model Google Lists as Shut Down Answered Me Today. Read `modelVersion` Before You Trust It.

ushiro — Mon, 21 Sep 2026 12:00:00 +0000

Google's Gemini deprecation page defines its terms up front:

Once a model is "shutdown", it is completely turned off, and the endpoint is no longer
available.

The same page marks already-shutdown models with a grey row, and gemini-3.1-flash-lite-preview
is grey. Shut down. Endpoint gone.

I called it on 2026-09-20:

curl -s "https://generativelanguage.googleapis.com/v1beta/models/\
gemini-3.1-flash-lite-preview:generateContent?key=$KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"What is 7 times 6? Answer with the number only."}]}]}'

HTTP 200
"42"

No error, no warning header, no notice in the payload.

One field says what actually happened

{
  "candidates": [ ... ],
  "modelVersion": "gemini-3.1-flash-lite",
  "usageMetadata": { "totalTokenCount": 16, "serviceTier": "standard" }
}

I asked for gemini-3.1-flash-lite-preview. I was served gemini-3.1-flash-lite — the GA model
named in the replacement column of the very row that says the preview is shut down.

Calling the GA name directly confirms they are the same thing now:

request = gemini-3.1-flash-lite          -> modelVersion = gemini-3.1-flash-lite
request = gemini-3.1-flash-lite-preview  -> modelVersion = gemini-3.1-flash-lite

The retired ID resolves to its successor. Your call succeeds. A different model answers it.

Before you generalise this — two things that are NOT the story

I went looking for "vendor ignores its own shutdown dates" and did not find it. Two corrections
I had to make to my own reasoning, both from reading the page more carefully:

The dates in that table are not shutdown dates. The page says so explicitly:

The shutdown dates listed in the table indicate the earliest possible dates on which a model
might be retired. We will communicate the exact shutdown date to users with advance notice.

So a model still running past the date in its row is not a broken promise. It is the documented
behaviour. Two other previews — gemini-3.1-flash-image-preview and gemini-3-pro-image-preview
— are past their June 25 dates and still live, and their rows are not grey. Google is not
claiming they are shut down. Nothing is wrong there.

The scope is small. Of the 32 rows the page marks as already shut down, exactly two still
appear in the live ListModels output:

gemini-3.1-flash-lite-preview   -> gemini-3.1-flash-lite   (generation verified)
gemini-2.5-pro-preview-tts      -> countTokens returns 200 (generation not tested)

Thirty of thirty-two are genuinely gone. This is a narrow gap, not a pattern of neglect.

Why the narrow version still matters

An alias is the kind choice. The alternative is a hard failure on the shutdown date, which takes
down every service still pointing at the old name — including the ones whose owners never read
the deprecation page. Google kept those callers running and pointed them at the model it had
already told everyone to migrate to. If your code is "call an LLM, get text back," this saved
you an outage and cost you nothing.

But nobody types -preview into a config file by accident. You pin a specific model ID for one
reason: you want the same model next month that you had this month.

That is the property the alias silently removes. Your request still succeeds, your tests still
pass, your error rate stays flat — and the weights answering are not the weights you evaluated
against. Prompts tuned on that preview, a golden-output suite, a published benchmark, a cached
embedding space, a customer-facing behaviour you signed off on: all measured against a model
that the vendor says is turned off.

The failure mode is not an outage. It is quiet drift behind a green dashboard.

Nobody has said how long this lasts

Here is the part I want to be clearest about, because it is the part that should change what you
do.

The aliasing is not documented anywhere I can find. The deprecation page does not mention
aliases, redirects, or fallbacks — the words do not appear on it. It says the opposite: that a
shut-down model's endpoint is no longer available. There is no stated policy for how long a
retired ID keeps resolving, no commitment that it will keep working tomorrow, and no announcement
channel for the day it stops.

Which means you cannot plan against it. The behaviour I measured today is not a feature you were
offered and it is not a guarantee you can hold anyone to. It is an undocumented grace period of
unknown length, and the day it ends, the failure will look exactly like the outage the alias was
preventing — except now it arrives with no date attached, because the date already passed months
ago and you stopped watching.

Treat it as time to migrate, not as a migration you can skip.

What to actually do

Log modelVersion on every call. One field, and the only thing in the response that tells
you what answered. If you store nothing else about a request, store this.

Assert on it where it matters. A suite that exists to prove your prompt still behaves should
fail when the model underneath changes, not when the output finally drifts far enough for a human
to notice:

const res = await model.generateContent(req);
if (res.modelVersion !== EXPECTED_MODEL) {
  throw new Error(`served by ${res.modelVersion}, pinned ${EXPECTED_MODEL}`);
}

Read a retirement row as "the answer may change", not "the call may fail". Those are
different events, and only one of them pages you.

Most LLM plumbing I see checks the status code and reads candidates[0]. Everything between
those two is treated as noise. Here the entire signal was in the noise.

Verified against the live pages and API on 2026-09-20. I keep a record of these dates and what
they said before they changed:
aichangewatch.com/deprecations

My CLS Was 0 Until I Throttled the Network. Then It Was 0.11.

ushiro — Fri, 18 Sep 2026 13:00:00 +0000

Every measurement I took said my Cumulative Layout Shift was 0. Lighthouse, a headless Chrome
run, reloading the page and staring at it — all zero. The pages were shifting anyway.

The number was wrong because of how I was loading the page, and the shift itself came from a CSS
selector I would have called harmless.

Why an unthrottled measurement reads zero

Layout shift needs two paints to happen. The browser lays something out, more bytes arrive, and
it lays it out differently.

On a fast connection to a nearby server, the entire HTML document lands in one chunk. There is no
second paint, so there is no shift to record — on a page that genuinely shifts for real users on
real connections. The measurement isn't noisy. It is confidently, reproducibly zero.

You have to slow the page down until the streaming actually streams.

// Drive Chrome over CDP: --headless=new --remote-debugging-port=9222
await client.send('Emulation.setCPUThrottlingRate', { rate: 4 });
await client.send('Network.emulateNetworkConditions', {
  offline: false,
  latency: 300,
  downloadThroughput: (0.5 * 1024 * 1024) / 8,
  uploadThroughput: (0.5 * 1024 * 1024) / 8,
});

And record the shifts with the sources attached, because a bare CLS number tells you nothing
about which element moved:

await client.send('Page.addScriptToEvaluateOnNewDocument', {
  source: `
    window.__shifts = [];
    new PerformanceObserver((list) => {
      for (const entry of list.getEntries()) {
        if (entry.hadRecentInput) continue;
        window.__shifts.push({
          value: entry.value,
          sources: entry.sources.map((s) => ({
            node: s.node && s.node.nodeName + '.' + (s.node.className || ''),
            from: s.previousRect,
            to: s.currentRect,
          })),
        });
      }
    }).observe({ type: 'layout-shift', buffered: true });
  `,
});

Cache-bust the URL on every run. A warm CDN edge undoes the throttling you just configured.

Throttled, the same pages that had measured 0 came back at 0.110 and 0.025.

The selector

The layout is a content column with an optional sidebar. Some pages have the sidebar, some don't,
and the shell was deciding for itself which case it was in:

/* Two columns, unless there is no rail inside me. */
.shell { grid-template-columns: minmax(0, 1fr) 274px; }
.shell:not(:has(.termrail)) { grid-template-columns: minmax(0, 1fr); }

That reads as elegant. The container asks a question about its own contents and answers it. No
prop drilling, no flag to keep in sync, no way for the class and the markup to disagree.

It is also a bet — that the child parses before first paint.

Where that bet loses

The rail is the shell's last child. Here is what that means on a real page of mine:

HTML document        407,197 characters
.shell opens at       11,722
.termrail appears at 134,567   ← 122,845 characters later

The browser sees .shell open, looks inside for .termrail, does not find it yet, and paints
the content column at full width. 122,845 characters later the rail arrives, :has() starts
matching, and the column is re-laid out 274px narrower.

Everything the user had already started reading moves left. That is the 0.110.

The bet wins on a short page — the whole thing arrives before first paint and :has() is right
the first time. It loses in exact proportion to how much HTML you ship, which means it fails worst
on your biggest, most content-heavy pages. Those are usually the ones that matter.

The fix is to move the decision earlier

The information was available on the server the whole time. The only reason it wasn't in the
markup is that :has() made it feel unnecessary.

// The server already knows whether this page has a rail.
<div className={keys.length ? 'shell has-rail' : 'shell'}>

.shell { grid-template-columns: minmax(0, 1fr) 274px; }
.shell:not(.has-rail) { grid-template-columns: minmax(0, 1fr); }

The class now rides the container's opening tag. On that page it lands 122,845 characters ahead
of the element it used to depend on. Re-measured under the same throttling: 0.

The rule I took from it

Not "avoid :has()". The rule is narrower:

Never gate a grid or flex track count on :has(<descendant>). Put the signal on the container's
opening tag.

Anything that changes how much space siblings get — column counts, track sizes, flex-basis,
display on a wrapper — is a layout decision, and a layout decision keyed off a later element is
a race you lose on long pages.

:has() is fine where being wrong for a moment costs nothing. These are still in my stylesheet
and I have no plans to remove them:

:root:has(.gl-page) { scroll-behavior: smooth; }

Nothing reflows if that flips halfway through the load.

Two things worth keeping

A performance number you measured without throttling is not a measurement. It is a statement
about your connection. The default in headless Chrome is your own network and CPU, and both are
faster than what your users have.

Watch entry.sources, not the score. The total told me there was a problem, once I could see
one at all. It was the previous and current rects on the sources array — a column that was 1180px
wide and became 906px — that named the element and pointed straight at the selector.

This came out of a project that crawls the docs of 15 AI vendors and records every change with
the date it happened: aichangewatch.com

Search Console Shows Your Canonical Tag. Googlebot Never Gets It.

ushiro — Tue, 15 Sep 2026 12:00:00 +0000

grep found my <link rel="canonical">. Search Console's URL Inspection showed it. It was still
landing outside <head> for the crawler that actually indexes the site.

Here is the check that finally showed it, on a dynamic route in Next.js 15.5:

#    HTML bytes   </head> at   canonical at
1       151,428        4,766         103,412

The tag exists. It is 98,000 characters past the end of the head.

Why `grep` can't see this

Every tool I reached for first answers a different question than the one that matters.

curl -s https://example.com/some-page | grep -c 'rel="canonical"'
# 1

That 1 is true and useless. Google ignores canonical and hreflang found outside <head>
in the raw HTML. React moves the tag into the head on the client, so a browser never shows you
anything wrong either — open DevTools and it is sitting in <head>, exactly where you put it.

The question is not whether the tag is present. It is whether it appears before </head>.

import urllib.request

UA = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
req = urllib.request.Request("https://example.com/some-page", headers={"User-Agent": UA})
html = urllib.request.urlopen(req).read().decode("utf-8", "ignore")

head, canon = html.find("</head>"), html.find('rel="canonical"')
print(head, canon, "inside" if 0 <= canon < head else "OUTSIDE")

The cause is a design decision, not a bug

Next 15.2+ streams metadata by default. The shell flushes as soon as the page body is ready, and
whatever generateMetadata returns is injected later — after </head> has already gone out on
the wire.

Next knows some clients cannot cope with that, so it keeps an exception list of user agents that
get a blocking render instead. It lives in next/dist/shared/lib/router/utils/html-bots.js:

const HTML_LIMITED_BOT_UA_RE =
  /[\w-]+-Google|Google-[\w-]+|Chrome-Lighthouse|Slurp|DuckDuckBot|baiduspider|yandex|sogou|bitlybot|tumblr|vkShare|quora link preview|redditbot|ia_archiver|Bingbot|BingPreview|applebot|facebookexternalhit|facebookcatalog|Twitterbot|LinkedInBot|Slackbot|Discordbot|WhatsApp|SkypeUriPreview|Yeti|googleweblight/i;

Read the two Google patterns closely. [\w-]+-Google matches anything ending in -Google.
Google-[\w-]+ matches anything starting with Google-. Neither one matches the string
Googlebot.

Run it yourself:

const { HTML_LIMITED_BOT_UA_RE: re } =
  require('next/dist/shared/lib/router/utils/html-bots.js');

for (const ua of ['Googlebot', 'AdsBot-Google', 'Mediapartners-Google',
                  'Google-InspectionTool', 'Bingbot', 'Applebot']) {
  console.log(re.test(ua) ? 'blocking ' : 'streaming', ua);
}

Output on next@15.5.21:

streaming Googlebot
blocking  AdsBot-Google
blocking  Mediapartners-Google
blocking  Google-InspectionTool
blocking  Bingbot
blocking  Applebot

This is deliberate. The reasoning is that Googlebot executes JavaScript, so it will see the tag
after React relocates it — but only if the URL reaches the rendering queue, which is a second
pass and not guaranteed. The ad crawlers and the link-preview bots, which genuinely only read raw
HTML, are on the list.

The part that cost me the most time

Google-InspectionTool is the user agent behind URL Inspection in Search Console.

It matches Google-[\w-]+. It gets a blocking render. So the one tool you would naturally reach
for to verify the problem is served a complete, correct document — while plain Googlebot, the
thing that actually crawls you, is served the streamed one.

Bingbot is on the list too, so Bing Webmaster Tools looks healthy as well. Two independent
consoles agreeing that everything is fine is not confirmation here. They are both talking to the
blocking path.

It only happens sometimes, and only on some routes

This is what kept it hidden. Two conditions have to line up.

It is timing-dependent. Fetch a URL once, on its own, and the metadata almost always lands
inside <head> — the response is fast enough that the injection wins the race. It surfaces under
back-to-back load, which is what a crawler actually does to you. Measured across 116
/{provider}/{category} URLs fetched in sequence:

User agent	canonical outside `<head>`
Chrome	21 / 116
Googlebot	16 / 116
Bingbot	0 / 116

Bingbot's zero is the control: same URLs, same moment, blocking render, never broken.

It is dynamic routes only. Anything served from ISR replays a complete, already-assembled
document, so the streaming race never happens. The x-nextjs-cache response header tells you
which kind of route you are looking at:

$ curl -sI https://example.com/some-hub | grep -i x-nextjs-cache
x-nextjs-cache: STALE      <- replayed from cache, safe

$ curl -sI https://example.com/some-dynamic-page | grep -i x-nextjs-cache
                           <- no header, rendered per request, at risk

If everything you serve is statically generated or ISR-cached, none of this applies to you.

The fix

htmlLimitedBots in next.config.mjs lets you supply your own regex. One catch worth knowing:
it replaces Next's list rather than extending it. base-server.js reads
config.htmlLimitedBots || HTML_LIMITED_BOT_UA_RE_STRING, so writing /Googlebot/i there would
silently drop Bingbot, Applebot, Twitterbot and everything else.

Build it from Next's own source, so the list cannot go stale underneath you:

import { createRequire } from 'node:module';
const require_ = createRequire(import.meta.url);

const FALLBACK = '[\\w-]+-Google|Google-[\\w-]+|Chrome-Lighthouse|Slurp|DuckDuckBot';

let nextBots;
try {
  nextBots = require_('next/dist/shared/lib/router/utils/html-bots.js')
    .HTML_LIMITED_BOT_UA_RE.source;
} catch {
  nextBots = FALLBACK; // only if that internal path moves
}

export default {
  htmlLimitedBots: new RegExp(`Googlebot|${nextBots}`, 'i'),
};

After deploying, the same back-to-back measurement:

canonical outside <head>, Googlebot UA:  0 / 116

Re-checked ten days later on a dynamic route, ten parallel requests: </head> at 4,766,
canonical at 2,248, every single time.

Blocking costs nothing at this size. Median response with a Googlebot UA was 144–317ms.
Bingbot — already blocking, on the same URLs — was 129–222ms. Browsers keep streaming, because
Chrome does not match the pattern.

What this is not

It is an indexing signal, not a reachability one. Canonical outside <head> never stopped a
single crawl, and it explains nothing about crawl volume, coverage, or a page missing from the
index entirely. I checked whether it explained my own indexing gap before believing that it did,
and it did not — the pages I most wanted indexed were ISR-cached, so their canonical had been in
<head> the whole time.

What it does mean is narrower, and still worth fixing: on dynamic routes, some fraction of
Googlebot's fetches were told nothing about which URL is canonical or which language alternates
exist. On a site with one URL per thing, that fraction is a rounding error. On a site with ten
locales pointing at the same content, it is the entire signal.

The general lesson is one I keep relearning. When you verify a crawler-facing behaviour, send the
crawler's user agent, and check the thing's position, not its presence.

This came out of a project that crawls the docs of 15 AI vendors and records every change with
the date it happened: aichangewatch.com

My "Last Hour" Query Returned 1,252 Rows. The Real Answer Was 68.

ushiro — Fri, 11 Sep 2026 12:00:00 +0000

I run AI Change Watch, a small independent project that
crawls what 15 AI vendors publish about their own models — deprecation tables, lifecycle pages, pricing
and SDK releases — and records every time one of them changes.

Every so often I check whether the crawler is still alive by counting recent runs. The query is the
obvious one:

SELECT COUNT(*) FROM crawl_runs
WHERE started_at > datetime('now', '-1 hour');

It returned 1,252. The true number of runs in that hour was 68.

No error. No warning. A plausible-looking integer, roughly eighteen times too large, from a query that
reads correctly in review.

The two halves of the comparison are different formats

crawl_runs.started_at is written by application code, as ISO 8601:

2026-08-24T17:40:41.965Z

SQLite's datetime() returns its own format, which uses a space instead of T and has no
fractional part or zone suffix:

sqlite> SELECT datetime('now', '-1 hour');
2026-08-24 16:54:52

Both are strings. SQLite has no dedicated date type — dates are TEXT, REAL or INTEGER by convention —
so > here is a text comparison, byte by byte.

And that is where it goes wrong, at exactly one character:

position 11	value	byte
stored	`T`	`0x54`
cutoff	`' '`	`0x20`

T sorts above a space. So for every row whose date part is the same day as the cutoff, the
comparison stops at position 11, finds 0x54 > 0x20, and answers greater — no matter what time it
actually is. A run from 00:03 that morning is "in the last hour."

The fix is to make the cutoff the same shape as the column:

-- wrong: 1252 rows
WHERE started_at > datetime('now', '-1 hour')

-- right: 68 rows
WHERE started_at > strftime('%Y-%m-%dT%H:%M:%SZ', 'now', '-1 hour')

Why it survived so long

Because both of its failure modes are comfortable.

For freshness checks it fails loud. The number comes out too big, which means a stalled crawler
still looks busy. This is the dangerous direction — it is precisely the check whose whole job is to tell
you something stopped, and it is biased toward saying everything is fine.

For windowed audits it fails safe. -1 day or -7 day pulls in the entire boundary day, so a
review window is wider than you stated, never narrower. Nothing is missed; you just quietly reviewed
more than you meant to. Nobody notices being handed extra.

Neither shows up in the output. You do not get a type error, a coercion warning, or an empty result that
makes you look twice. You get rows, and they are real rows, and they are formatted like the ones you
wanted.

Where this bug actually lives

Here is the part I found most interesting once I went looking. My shipped code was never affected.

Nothing under src/ or web/ calls SQLite's datetime('now') or julianday('now') at all. Every
bound in the application is built in JavaScript:

const since = new Date(Date.now() - 86_400_000).toISOString();
// '2026-08-23T17:40:41.965Z'  — same shape as the column

Which emits the identical T/Z form, so the comparison is like-for-like everywhere it ships.

The bug lived entirely in hand-written operational queries — the ones I type into a console to
answer a question right now. That is the least-examined code in any project:

no test covers it
no reviewer reads it
it exists for ninety seconds and produces a number you then repeat to someone

Several "runs in the last hour" figures I had quoted before finding this were inflated by it. The
application was healthy the whole time; the instrument was wrong.

If you can't change the format on both sides

Two escape hatches, in the order I'd reach for them.

Normalise the cutoff, not the column. Rewriting stored data is a migration; rewriting a cutoff is a
line. strftime above is the clean version, but if you already have datetime() calls scattered through
a script, patching them in place also works:

WHERE started_at > replace(datetime('now', '-1 hour'), ' ', 'T') || 'Z'

I prefer strftime — it states the format it produces instead of repairing one — but this is fine when
you are editing twenty ad-hoc queries and want a mechanical change.

Or stop storing dates as text. SQLite has no date type; the documentation offers three conventions —
ISO-8601 TEXT, Julian day as REAL, and Unix epoch as INTEGER — and the whole class of bug in this post
only exists in the first one. Integers compare as numbers, so there is no format to disagree about:

WHERE started_at_ms > (unixepoch('now', '-1 hour') * 1000)

The trade is readability. 1787143241965 in a console tells you nothing, and every query you write by
hand now needs a conversion to be legible. For a table I mostly read by eye I kept the text column and
fixed the cutoffs. For one I only ever compared, I would not.

Worth knowing which trade you made, rather than discovering it at position 11 of a string.

How to find this in your own code

Grep for the mixed forms. If both of these return hits in the same project, you have the ingredients:

rg "datetime\('now'|julianday\('now'"     # SQL-side clocks
rg "toISOString\(\)"                      # JS-side timestamps

The bug is not either one. It's a comparison with one of each on opposite sides.

Cross-check any window with a grouping. This is the cheap, general test, and it needs no knowledge of
the storage format:

SELECT substr(started_at, 1, 13) AS hour, COUNT(*)
FROM crawl_runs
GROUP BY hour ORDER BY hour DESC LIMIT 5;

If the hourly buckets don't sum to what your windowed query claimed, the comparison is the reason. That
is how I found the 68.

Look at your columns before you compare them. One SELECT started_at FROM crawl_runs LIMIT 1 would
have shown me the T at any point in the preceding months.

The general form of this, which is not really about SQLite: a comparison between two values that were
produced by different systems is a format assumption, whether or not you wrote it down. Text
comparison will not tell you when the assumption is wrong. It will answer the question you literally
asked, in a shape indistinguishable from the answer you wanted.

Found 2026-08-24, fixed the same day. The tracker this came out of is at
aichangewatch.com — it records what AI vendors change in their
own docs, which involves a lot of timestamps that have to be comparable across sources.

"Application error: a client-side exception has occurred" Is a Stale Chunk 404

ushiro — Tue, 08 Sep 2026 12:00:00 +0000

For a while it would, occasionally, break in the browser after I shipped something. Not on load — on the
next click.

The symptom

You have the site open. You navigate — Home, a provider page, anything with a client transition. Instead
of the page you get a white screen and one line:

Application error: a client-side exception has occurred
(see the browser console for more information)

Reload and it's gone. Everything works. You can't reproduce it on demand.

Two properties make this genuinely hard to place:

It's intermittent. It hits some tabs and not others, some navigations and not others.
The message is deliberately empty. That string is React's production error boundary refusing to leak details. It is the same message for every uncaught render error, so it tells you nothing about which one you have.

The trap: the server is fine, and that misleads you

The first thing I did was look at the server. All of it was clean:

$ wrangler tail changewatch-web
... "exceptions": [] ... "exceptions": [] ... "exceptions": [] ...

Every request. And Home returned 200 across every filter, every provider, every page size I tried. No
500, no thrown exception, no failed render.

That reads as "the server is healthy, so the bug is in my component code" — and it sends you into the
one place the problem is not. It took me longer than it should have to state the actual reason the logs
were empty:

Worker logs never contain client exceptions. The error happened in the browser, after the response
was delivered and logged as a success. A clean server log is not evidence about the client. It's silence
about the client.

The one request that names it

Open DevTools, keep the Network tab open, and reproduce the navigation. You are looking for a 404 on a
/_next/static/... path:

GET /_next/static/chunks/app/[locale]/layout-4f2c9a1b8e.js   404

If it's there, you are done diagnosing. That is deployment skew, and the underlying error is a
ChunkLoadError — React caught it, and the boundary printed the generic line.

You can confirm it in the Console, which will have the real message that the page refused to show you:

ChunkLoadError: Loading chunk app/[locale]/layout failed.
(error: https://.../_next/static/chunks/app/[locale]/layout-4f2c9a1b8e.js)

Why a redeploy does this

Next.js splits your app into hashed chunks and loads them on demand. A page you open is not the whole
app — it's an HTML document plus the chunks needed so far. The chunks for a route you haven't visited
yet are fetched at the moment you navigate there.

The hash in a chunk's filename is derived from its contents. Change layout.tsx and
layout-4f2c9a1b8e.js becomes layout-91d0c73aa2.js.

Now put those two facts together with how static assets are hosted. On Workers Assets — and on most
static hosting, this is not Cloudflare-specific — only the current build's assets exist. Deploying
replaces the set. The old hashed filenames stop resolving.

So the sequence is:

A browser loads the site on build A. The document and the initial chunks are A's.
You deploy build B. A's chunk files are gone.
That still-open tab navigates. It requests the chunk name it learned from A.
404. ChunkLoadError. Generic error boundary.

Which explains both properties from the top. Intermittent, because it only affects tabs that were
loaded before the deploy and then navigated after it. Fixed by reload, because a reload fetches the
new document, which references B's chunk names.

It also explains why this feels like it's getting worse when you're actively working: during a session
where you deploy six times in an hour, every tab you left open is a candidate. At a normal release
cadence it only touches people who happened to have the site open across the deploy.

Two fixes, and they are not equivalent

Recover automatically. Add an error boundary that recognises this specific failure and reloads
instead of rendering the message:

// app/[locale]/error.tsx
'use client';

export default function Error({ error }: { error: Error }) {
  if (error.name === 'ChunkLoadError') {
    window.location.reload();
    return null;
  }
  return <p>Something went wrong.</p>;
}

This is the honest fix for a user-facing site: the reload is what the visitor would have done anyway, so
do it for them. The cost is that you have taken a class of error and made it invisible — if something
else ever produces a ChunkLoadError, you now have a silent reload loop instead of a report.

Keep old builds around. Some platforms let you retain previous deployments' static assets so old
chunk names keep resolving for a while. This removes the 404 rather than reacting to it, and it is
strictly better where it's available. It was not an option for me.

I went with neither, deliberately. My traffic is small, my deploys are frequent, and the failure costs a
reload — so I recorded what it was, in writing, and stopped investigating it. The expensive part of
this bug was never the impact. It was the three separate times I opened the wrong file looking for it.

The general shape

The thing I'd actually want to keep from this:

A generic error message plus a clean server log is a specific combination, not an absence of
information. It means the failure is downstream of your logs — in the browser, in the CDN, in the
network — and it should send you to a different tool, not to a closer reading of your components. I kept
re-reading the server side because that was the side I could see.

A hashed filename is a contract with a build that may no longer exist. Anything that caches, retries,
prefetches or holds a reference across a deploy is exposed to it. Long-lived tabs are just the most
common case.

Reproduce it before you fix it. You can trigger this on demand: open the site, deploy, then click a
link in the old tab without reloading. If it doesn't reproduce, you have a different problem, and the
error boundary above would have hidden it from you.

`No test suite found in file` on All 71 Files: Your `vite` Override Has No Upper Bound

ushiro — Fri, 04 Sep 2026 12:00:00 +0000

pnpm test had been ending like this for a while:

 ❯ test/analyzeChange.test.ts  (0 test)
 ❯ test/rowMapper.test.ts      (0 test)
 ... 69 more ...

 Test Files  no tests
      Tests  no tests

Every one of the 71 files printed No test suite found in file, and the run exited non-zero.

I read that as a config problem. It looks exactly like one: a bad include glob, a projects entry
pointing at the wrong directory, a environment mismatch — the kind of thing where the runner is fine
and your setup is wrong. So it sat there. Meanwhile the actual state was that 845 tests had not
executed once in that window, and nothing on the screen said so in those words.

The cause was a line I had written myself, for a good reason, four months earlier.

A security override with no upper bound

In pnpm-workspace.yaml:

overrides:
  # Security patch: dev-only vite advisories (fs.deny bypass / path traversal / launch-editor).
  # Force the patched vite that vitest transitively pulls. Not shipped to production.
  vite: ">=6.4.3"

I don't depend on vite directly. It arrives transitively under vitest. A batch of dev-only advisories
came out, the patched version was 6.4.3, and an override was the shortest way to guarantee every copy in
the tree was at or above it.

>=6.4.3 is not a pin. It is an open-ended range, and an override outranks whatever the dependent
declares. So when vite 8.1.4 shipped, pnpm resolved it — even though vitest 3.2.7 declares
^5 || ^6 || ^7.0.0-0, which does not include 8.

That is the part worth internalising: the peer range vitest publishes is exactly the guard that would
have stopped this, and overrides is the mechanism that tells the resolver to ignore it. I had opted
out of the safety check and left a note explaining why, and the note said nothing about the ceiling
because at the time there was nothing above.

Why vite 8 produced zero suites instead of an error

Vite 8 moved its transform pipeline to rolldown/oxc, and the module-runner contract changed with it.
Vitest loaded all 71 files without throwing, evaluated them, and got no registered suites back.

From the runner's point of view that is indistinguishable from a file with no describe/test in it —
so it reported the honest thing it could see, once per file:

No test suite found in file

There was one fingerprint of the real cause in the noise, and I had been scrolling past it:

The `esbuild` option is deprecated, please use `oxc` instead

That warning is vite 8 announcing itself. Nothing in the output ever named a version mismatch.

The fix is one character class

  # Capped below 8, and the missing cap is why the ENTIRE test suite was dead. This range had no upper
  # bound, so vite resolved to 8.1.4 while vitest 3.2.7 declares ^5||^6||^7.0.0-0. Vite 8 moved to
  # rolldown/oxc and changed the module-runner contract: vitest loaded all 71 test files, got no suites
  # back, and reported "No test suite found in file" for every one of them. `vitest run` then exits
  # non-zero with "Tests: no tests" — which reads like a config problem, not like 71 silently unrun
  # files, and it stayed unnoticed. Nothing else in either workspace depends on vite (`pnpm why vite`
  # lists only vitest, vite-node and @vitest/mocker), so the cap costs nothing. Raise it when vitest
  # supports vite 8.
  vite: ">=6.4.3 <8"

Before adding a cap, check who is actually asking for the package:

$ pnpm why vite
  vitest
  vite-node
  @vitest/mocker

Only the test runner. Nothing in either workspace consumes vite at build time or ships it to
production, so constraining it has no blast radius. If the answer had included the framework or the
bundler, the cap would have been a real decision instead of a free one.

vite dropped to 7.3.6. All 71 files collected. 845 tests, all passing.

Then one of them failed

Not a regression from the dead window — the suite came back clean on everything that had been touched
while it was down. The failure was older than that, and it was real.

lifecycleColumns() reads the extracted facts for a deprecation event and turns them into database
columns. It handled the shutdown date and the successor model:

for (const f of facts) {
  const after = typeof f.after === 'string' ? f.after : undefined;
  if (!after) continue;
  if (f.kind === 'date' && / shutdown$/.test(f.label)) {
    if (!shutdownAt || after < shutdownAt) shutdownAt = after;
  } else if (f.kind === 'model' && / successor$/.test(f.label) && !successor) {
    successor = after;
  }
}

There is no branch for the deprecated date. So events.announced_at was NULL — not for some rows,
for every row ever written.

That column is the start of the notice period. Without it you cannot compute how much warning a vendor
actually gave before switching a model off, which for a site whose entire subject is model lifecycles is
not a cosmetic gap.

The test that catches it already existed, and had existed the whole time. Its name is
shutdown date, successor and announcement date, and thirty lines up it verifies the occurredAt value
'2025-06-10T00:00:00.000Z' — the vendor's own "deprecated on" column. The extraction was there. The
assertion was there. Only the mapping to a database column was missing, and the one process that would
have said so was returning no tests.

The fix is the missing branch:

} else if (f.kind === 'date' && / deprecated$/.test(f.label)) {
  // Earliest, for the same reason as shutdownAt: on a batch announcement the notice period a reader
  // is actually inside is the one that started first.
  if (!deprecatedAt || after < deprecatedAt) deprecatedAt = after;
}

The second guard was also down

While fixing that I ran the type checker, which I had not done in a while either:

$ pnpm run typecheck
$ echo $?
2

rowMapper.ts line 98 was reading a deprecatedAt field off the return value of a function whose
declared return type did not have one. It could not compile. CI was in the same state.

So both automated checks on this repository were failing, in two different ways, and neither of them was
loud enough to interrupt anyone. One said no tests and looked like configuration. The other exited 2 in
a step nobody was reading.

What I changed afterwards

A security override needs an upper bound too. The reason you write one is that you know better than
the resolver about a specific lower edge. That knowledge does not extend upward. >=x published today
is a bet on every major version that ships after you stop paying attention.

no tests is a failure state, not a neutral one. A run that collects zero suites should be treated
the same as a run that fails, because the information content is identical: you do not know whether your
code works. It exits non-zero already; the gap was in my reading, not in the tool.

Check the peer range before overriding. vitest 3.2.7 → ^5 || ^6 || ^7.0.0-0 was a two-second lookup
that would have told me exactly where the ceiling belonged.

The existing announced_at values are still NULL. Backfilling them needs a re-parse of the archived
page snapshots, which is a separate job. The column is populated correctly going forward.

I write these up while building AI Change Watch, which crawls
LLM vendor documentation and records every deprecation, shutdown date and price change with the date it
happened.

A `middleware.ts` Rewrite Silently Disables ISR in Next.js 15.5

ushiro — Tue, 01 Sep 2026 12:00:00 +0000

Every page on my site declared export const revalidate = 300. Nine locales served from ISR.
The tenth — the one that is actually canonical, the one crawlers hit most — re-rendered from scratch
on every single request for weeks.

The difference between them was not a page, a config flag, or a deployment. It was that the tenth
locale's URL went through a NextResponse.rewrite() in middleware.ts.

I run AI Change Watch, a Next.js App Router site on Cloudflare
Workers (via OpenNext) that crawls what AI vendors publish about their own models and records every
change. en is served unprefixed (/deprecations), the other nine locales are prefixed
(/ja/deprecations). That unprefixed mapping was one line of middleware.

What the headers said

Measured on production, 2026-08-06. Same page, same component tree, same revalidate = 300 — only
the routing path differs:

/bot, /rankings                (rewritten in middleware)
  Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
  (no x-nextjs-* headers at all)

/ja/bot, /ja/rankings          (passed through with next())
  Cache-Control: s-maxage=300, stale-while-revalidate=...
  x-nextjs-prerender: 1

private, no-store on a page whose whole point is to be cached. And not "cached badly" — there are
no x-nextjs-* headers on those responses whatsoever, which means Next never treated the request as
a route that has an incremental cache entry. Nothing was written, so nothing could ever be read.

Why this hides so well

Three things kept this invisible for weeks, and I think each one is general.

The prefixed locales are fine. Any "is my ISR working?" check you run against /ja/... passes.
The bug is per-path, and it only touches the paths middleware rewrote.

Probing the prefixed form of the broken URL measures nothing. /en/bot 307-redirects to the
canonical /bot (verified again today), so curl -I /en/bot returns a redirect and tells you
nothing about the page. You have to test the unprefixed URL. I burned an eight-minute polling
loop on /en/bot before noticing that.

Pages still refresh, so content never looks stale. Deploys change the buildId, the buildId is part
of the cache key space, and this repo deploys several times a day — so the whole cache was being
invalidated often enough that no page was ever visibly out of date. revalidate = 300 was decorative,
and deployment frequency was covering for it. (There was a second, independent reason revalidation
never ran on this stack; that one is
its own post.)

The cause

This is vercel/next.js#83862 — "SWR Cache-Control
disabled after Next.js 15.5 when using a rewrite middleware", open, filed 2025-09-16, reported
against 15.4.2-canary.2 through 15.5.3. I reproduce it on 15.5.21.

The explanation in the issue is that Next matches the pre-rewrite path against the
dynamic-route regexes. /bot matches nothing (the real route is app/[locale]/[provider]/page.tsx),
so the response falls back to the private, no-store default. That mechanism is upstream's account
and the internals are not something I can observe from outside; what I can state is the header pair
above, and that it flips based solely on whether the rewrite happened in middleware.

The important consequence is that it is a write-side failure, not a read-side one. No entry is
ever created for those keys. So nothing that improves cache lookup can help.

Two things that did not fix it

Rewriting the rewrite. There is no shape of NextResponse.rewrite() that avoids this. It is not
a matcher problem or an ordering problem.

Serving ISR from the adapter's routing layer (OpenNext's enableCacheInterception: true) looked
like the perfect workaround: resolve the cache before NextServer is ever invoked, and the pre-rewrite
path matching stops mattering. Cache hits did work — I have x-opennext-cache: HIT on prefixed
locales to prove it. It still could not fix English, because the cache was empty for those keys, and
then it took the site down:

Error in routingHandler
  at Object.send (worker.js:116290)     at computeCacheControl (worker.js:120329)
  at generateResult (worker.js:120394)  at cacheInterceptor (worker.js:121493)

On a stale entry the interceptor has to dispatch the background re-render itself, and at that
point I had no revalidation queue bound. Inside NextServer that same failure is caught and logged as
a warning. In the routing layer it wasn't caught, so the request returned 500. Two properties made it
much worse than an ordinary bug: it threw before the render, so the entry could never refresh and
the 500 was permanent per URL; and it only fired once an entry passed its revalidate window, so
pages died one at a time over several hours — 12 URLs before I reverted it.

If you take one thing from this post, take that shape: a failure that is caught in one layer and
uncaught in the layer you moved it to.

The fix

Move the rewrite out of middleware and into next.config.mjs. A config rewrite lands in the routes
manifest, which the adapter's routing layer applies to the internal request, so NextServer receives a
plain /en/... request with no x-middleware-rewrite header — the exact path /ja/... always took.

async rewrites() {
  const reserved = 'en|ja|zh|es|de|fr|ko|pt|it|tr|api|_next|sitemaps';
  return {
    afterFiles: [
      { source: '/', destination: '/en' },
      { source: `/:seg((?!(?:${reserved})(?:/|$))[^/]+)`, destination: '/en/:seg' },
      { source: `/:seg((?!(?:${reserved})(?:/|$))[^/]+)/:rest*`, destination: '/en/:seg/:rest*' },
    ],
  };
}

Middleware keeps the /en/... → /... redirect. Redirects are unaffected; only rewrites are.

afterFiles, not beforeFiles. afterFiles runs only when no real route matched, so
/sitemap.xml, /robots.txt, /icon.svg and friends resolve as themselves before this pattern is
consulted, and drop out of the exclusion list for free. With beforeFiles every one of them needs an
explicit exclusion, and each missing exclusion is a 404 on a canonical URL.

The exclusion regex has two traps

Both of these produce a config that builds fine and 404s in production.

Trap 1: anchor each alternative to a segment boundary. The negative lookahead has to end with
(?:/|$), not $. With $ alone it only fires when the reserved word ends the path:

                 $ only                    (?:/|$)
/bot          -> /en/bot                 -> /en/bot
/ja/bot       -> /en/ja/bot   ← 404      -> (no rewrite)  ✓
/en/bot       -> /en/en/bot   ← 404      -> (no rewrite)  ✓
/api/contact  -> /en/api/contact ← 404   -> (no rewrite)  ✓
/sitemaps/1   -> /en/sitemaps/1 ← 404    -> (no rewrite)  ✓

That table is RegExp.exec output, not a sketch. It is also the same family of bug as writing bare
api in a matcher, which swallows /api-features — a page of mine that 404'd on its canonical URL
for exactly that reason.

Trap 2: root-level dynamic routes are not protected. The "real routes win first" property of
afterFiles is gated on the adapter's static route matcher. /sitemaps/[id] is root-level and
dynamic, so it is not covered, and it has to be named in reserved by hand. If you add a root-level
dynamic route later, it needs the same entry — there is nothing to remind you.

How to check it, in the order that actually works

1. Test the compiled regex, not the source string. What runs is the pattern Next compiles into
.next/routes-manifest.json, and it is not what you typed. Build to a scratch directory
(NEXT_DIST_DIR=.next-rwtest next build), read the manifest, and assert every URL class you care
about — locale-prefixed, /en/-prefixed, /api/*, /_next/*, root-level files, root-level dynamic
routes, the feeds. All four shadowing bugs above were caught this way before deploying, and none of
them was visible in the source.

2. Then check the unprefixed URL on production. Today, on the same pages, 2026-08-27:

$ curl -sI https://aichangewatch.com/bot | grep -i 'cache\|nextjs'
Cache-Control: s-maxage=3600, stale-while-revalidate=31532400
x-nextjs-cache: STALE
x-nextjs-prerender: 1
x-nextjs-stale-time: 300

$ curl -sI https://aichangewatch.com/deprecations | grep -i 'nextjs'
x-nextjs-cache: HIT
x-nextjs-prerender: 1

x-nextjs-prerender: 1 is the header that was absent before, and it is the one to look for.
x-nextjs-cache: MISS on its own proves nothing — that is the earlier post's subject.

What I still haven't proven

Whether this reproduces off this adapter. Every measurement here is Next 15.5.21 + @opennextjs/cloudflare on Cloudflare Workers. The upstream issue is not adapter-specific and the reporters were not on my stack, but I have not tested Vercel or a plain next start myself.
Why the no-store fallback is chosen. I am quoting the issue's explanation of the path matching, not something I read out of the runtime.
The 500 attribution. That the interceptor threw at Object.send before the render is read off the stack trace and the fact that the 500s stopped on revert. I did not instrument it.

If you serve a default locale unprefixed on App Router, the check is one command and the failing case
looks completely healthy: full-SSR responses are correct, just uncached. Test the URL your users get,
not the internal one.

The site this came out of is AI Change Watch — vendor deprecation
tables, pricing and SDK changelogs, diffed on a schedule. The pages in the measurements above are
real ones; /deprecations is the one with the highest cache-hit value, which is why it was the first
thing I noticed serving no-store.

The iCalendar Spec Says 75 Octets, Not 75 Characters

ushiro — Thu, 27 Aug 2026 12:00:00 +0000

One of the things it publishes is a subscribable calendar: every announced model shutdown, as .ics,
so a date the vendor moves updates in your calendar instead of in a changelog you forgot to read.

The English feed worked immediately. The Japanese one was rejected.

Same code. Same events. The only difference was the language of the text inside.

The line that RFC 5545 actually specifies

Section 3.1:

Lines of text SHOULD NOT be longer than 75 octets, excluding the line break.

Not 75 characters. 75 octets.

For ASCII those are the same number, which is exactly why this survives every test you are likely to
write. SUMMARY:gpt-4-32k shutdown (OpenAI) is 36 characters and 36 bytes. Nothing to notice.

Then the same field comes back translated:

SUMMARY:code-davinci-001 提供終了（OpenAI）

That is 30 characters. It is 49 octets — Japanese runs about 3 bytes per character in UTF-8. A
folder that counts characters looks at 30, decides no fold is needed, and emits a line that is legal by
its own arithmetic and illegal by the spec's.

Longer titles cross 75 octets while still well under 75 characters, and that is the line the parser
rejects.

Why counting characters isn't the only bug

The obvious fix — count bytes instead — introduces a second one if you write it the obvious way.

// Still broken.
const bytes = Buffer.from(line, 'utf8');
for (let i = 0; i < bytes.length; i += 75) {
  out.push(bytes.subarray(i, i + 75).toString('utf8'));
}

Slicing a UTF-8 buffer at a fixed offset cuts through the middle of a character. Byte 75 lands in
the second of the three bytes that make up 終, and you emit half a codepoint on one line and the other
half on the next. Some parsers replace it with U+FFFD, some abort the file.

So the fold has to be counted in bytes but taken at character boundaries:

export function foldLine(line) {
  const enc = new TextEncoder();
  if (enc.encode(line).length <= 75) return line;

  const out = [];
  let cur = '', curBytes = 0;
  // The first line gets 75 octets; every continuation gets 74, because the leading
  // space that marks it as a continuation counts toward the limit too.
  let limit = 75;

  for (const ch of line) {          // iterating a string yields whole codepoints
    const n = enc.encode(ch).length;
    if (curBytes + n > limit) {
      out.push(cur);
      cur = ''; curBytes = 0; limit = 74;
    }
    cur += ch;
    curBytes += n;
  }
  if (cur) out.push(cur);

  return out.map((l, i) => (i === 0 ? l : ` ${l}`)).join('\r\n');
}

Three things in there are easy to leave out and each one produces a file that mostly works:

for (const ch of line), not line[i]. Indexing a JS string walks UTF-16 code units, so an emoji
or any astral-plane character gets split at the surrogate pair. Iterating with for...of yields whole
codepoints.

The limit drops from 75 to 74 after the first line. The continuation marker is a single leading
space and it counts. Keep the limit at 75 and every folded line is one octet over — which is the same
bug you just fixed, only harder to see because it only shows up on lines long enough to fold.

\r\n, not \n. RFC 5545 wants CRLF. Plenty of parsers tolerate bare LF, right up until one
doesn't.

The other one: your UID is not a display string

An .ics feed served in ten languages raises a question the spec answers but does not warn you about:
what is the UID?

If you build it from the localized summary, the same shutdown gets a different UID in every language.
Subscribe to two of them and your calendar shows two entries for one event, forever, with no way to
tell they are the same thing.

So the UID has to be keyed on the entity, never the presentation:

UID:shutdown-o1-preview@aichangewatch.com
UID:shutdown-davinci-002@aichangewatch.com

Model slug, no locale. I checked the two live feeds while writing this:

en feed:  262 UIDs
ja feed:  262 UIDs
shared:   262            ← identical sets

Which means a person subscribed to both gets one entry per shutdown, not two. The second subscription
overwrites the first rather than duplicating it. That is the correct failure mode — a collision beats
a double-booking, because a duplicate calendar entry is something the user has to notice and clean up by
hand.

It also means you cannot use the UID to carry the language. If you need that, it belongs in the calendar
name (X-WR-CALNAME), not the identity.

What I check now

The whole class is "a spec said octets and I read characters", and it is worth one assertion in a test
rather than a careful reading:

const body = renderCalendar(events);
for (const line of body.split('\r\n')) {
  expect(Buffer.byteLength(line, 'utf8')).toBeLessThanOrEqual(75);
}

Run it against the localized feed, not the English one. The English feed cannot fail this test,
which is precisely why it is not the one to run it on. Mine currently reports:

en feed:  6,545 lines,   0 over 75 octets,  506 continuation lines
ja feed:  6,606 lines,   0 over 75 octets,  567 continuation lines

The 61 extra lines in the Japanese feed are the folds the English one does not need. That gap is the
bug, made visible: same events, same code, more lines — because the same sentences take more bytes.

The tracker this came out of is at aichangewatch.com — the
shutdown calendar it generates is at
/deprecations/calendar.ics.

`next dev` Renders but Nothing Works: Your CSP Is Missing `unsafe-eval`

ushiro — Mon, 24 Aug 2026 12:00:00 +0000

At some point I added a Content-Security-Policy. It was correct. It shipped. Production was fine.

And then, locally, every interactive thing on the site stopped working.

The symptom

next dev starts. The page loads. It looks exactly right — the layout, the data, the styles, all
of it. Then:

the search box accepts text and filters nothing
the sort headers don't sort
the "show more" button does nothing
no onClick anywhere fires

No error page. No red overlay. No failed request in the Network tab. The server rendered the HTML and
sent it, so the page you are looking at is real — it is just completely inert. Nothing hydrated.

If you have not hit this before, the natural first guess is your own component. That is where I went,
and it is the wrong place, because every component is fine.

The one line that names it

The console has it, but you have to be looking:

Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an
allowed source of script in the following Content Security Policy directive:
"script-src 'self' 'unsafe-inline' …"

And the reason it is easy to miss is that it is not a JavaScript error. It does not have a stack. It
does not point at your file. It appears once, near the top, above whatever else the page logged, and it
names a directive rather than a component.

Why this happens in dev and not in prod

Next's development server compiles modules and hands them to the browser wrapped in eval — that is
how the dev devtool setting works, and it is what React Refresh needs to swap a component without
reloading the page. Fast Refresh is built on it.

A production build does not do that. next build emits static chunks. There is no string being
evaluated at runtime, so there is nothing for 'unsafe-eval' to permit.

Which produces the trap:

The CSP is correct for production and fatal in development — and development is where you spend all
your time.

You will not catch it in CI, because CI builds. You will not catch it in preview, because preview
builds. You catch it the moment you try to click something locally, and by then you are three commits
into a feature and looking for the bug in your own diff.

Why the header reaches dev at all

Because it is in next.config, and that file has no idea which mode it is running in unless you tell
it:

// next.config.mjs
async headers() {
  return [{ source: '/:path*', headers: securityHeaders }];
},

source: '/:path*' means every path. There is no dev/prod branch, so next dev serves the same header
next start does. That is a reasonable default — you generally want to develop against the headers
you ship — it just happens to be wrong for this one directive.

Two fixes, and they are not equivalent

Option A — widen the policy in development only.

const isDev = process.env.NODE_ENV === 'development';

const csp = [
  "default-src 'self'",
  // 'unsafe-eval' is DEV-ONLY: the dev server evaluates compiled modules as strings (that is what
  // React Refresh is built on), and a production build never does. Shipping it would be a real
  // widening of the policy for zero benefit.
  `script-src 'self' 'unsafe-inline'${isDev ? " 'unsafe-eval'" : ''}`,
  // The HMR socket, same reasoning. In production nothing connects back to the dev server.
  `connect-src 'self'${isDev ? ' ws: wss:' : ''}`,
  // …the rest
].join('; ');

The comment is not decoration. A conditional in a security header is exactly the kind of line that gets
"cleaned up" six months later by someone who reads it as an inconsistency, so the reason it is
conditional has to sit next to it.

Option B — stop testing client behaviour in next dev.

next build && next start

This is what I actually do, for a reason that has nothing to do with CSP: this project deploys to
Cloudflare Workers through OpenNext, and next dev is not the runtime it ships on. Behaviour I verify
in dev is behaviour I verified somewhere the code will never run. So for anything client-side I build
and serve the real thing.

The cost is real — you lose Fast Refresh, and a rebuild per change is slow enough to change how you
work. If your production runtime is Node, Option A is the better trade. If it isn't, Option B was
going to be necessary anyway and this just makes it obvious sooner.

The general shape

The thing worth taking away isn't the directive. It's this:

A security header set in next.config applies to the dev server, and the dev server has different
requirements than the thing you deploy.

unsafe-eval is the one that produces a silent failure, which is why it costs the most time. But the
same category catches you elsewhere:

directive	what dev needs that prod doesn't
`script-src`	`'unsafe-eval'` for the module runtime / React Refresh
`connect-src`	`ws:` / `wss:` for the HMR socket
`style-src`	`'unsafe-inline'` if your prod build extracts CSS but dev injects it

If you are about to add a CSP to a Next app, the fastest check is not a code review. It is:

next dev
open the page
click something
read the console — the first line, not the last

Thirty seconds, and it is the only test that distinguishes "rendered" from "working". Everything else
about a dead page looks identical to a live one.

The tracker this came out of is at aichangewatch.com — it watches AI
vendor docs for changes. Its CSP still has no 'unsafe-eval' in production, which is the point.

Your Worker Returned 500 and the Log Says `outcome: "ok"`

ushiro — Fri, 21 Aug 2026 12:00:00 +0000

It runs on Cloudflare Workers, which means that when someone tells me "your site 500'd an hour ago",
the obvious tool is useless. wrangler tail is a live stream. It shows you what is happening now.
It cannot show you an hour ago.

There is a way to read the past, and there are four traps in it that cost me most of a day.

The part that works

Workers can write their invocation logs to a queryable store, and a REST endpoint reads it back. First
the worker has to be opted in — this is the whole config:

// wrangler.jsonc
{
  "observability": { "enabled": true }
}

Then you can ask for events in a time range:

curl -sX POST \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT/workers/observability/telemetry/query" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "queryId": "anything",
    "timeframe": { "from": 1786000000000, "to": 1786003600000 },
    "limit": 500,
    "view": "events",
    "parameters": {
      "datasets": ["cloudflare-workers"],
      "filters": [
        { "id": "f1", "key": "$workers.event.response.status",
          "type": "number", "operation": "eq", "value": 500 }
      ]
    }
  }'

from and to are epoch milliseconds, not ISO strings. A read-scoped API token is enough — the
one I already had for deploys worked unchanged.

Each event carries more than you would guess:

$workers.outcome                              ok | exceededCpu | canceled
$workers.cpuTimeMs  /  $workers.wallTimeMs
$workers.event.request.path  /  .search
$workers.event.request.headers['user-agent']
$workers.event.request.cf.asOrganization      the ASN owner
$workers.event.response.status
$metadata.error

That is the tool. Now the traps.

Trap 1: a rendered 500 is a successful invocation

I started by filtering on the field that sounds right:

{ "key": "$workers.outcome", "operation": "eq", "value": "exceededCpu" }

and found nothing, repeatedly, while the site was demonstrably returning 500s.

Because for every one of them:

$workers.outcome = "ok"

The worker ran. It produced a response. It returned it. That the response was an error page is not the
runtime's problem — the invocation succeeded. outcome describes the worker, not the HTTP result.

So outcome is the wrong axis for application errors. Filter on $workers.event.response.status for
what the user saw, and read $metadata.error for the throw. outcome is for failures the runtime
itself noticed: CPU limit, cancellation.

This is worth internalising because it inverts the usual relationship. In most stacks "the request
failed" and "the handler failed" are the same event. At the edge they are two different fields — and
the one with the friendlier name is the one that will not tell you.

Trap 2: a wide time window silently undercounts

This is the one that actually cost me the day.

I asked for 5xx across a 24-hour window, got nine events, and concluded I was chasing a single bug. The
same 24 hours, walked in 4-hour slices and concatenated, returned 956 — across 92 URLs and three
unrelated causes.

I re-ran the comparison today, on 404s, to check it was not a one-off:

24h asked as one query      →  26 events
same 24h in 4h slices       → 266 events

The single query returned 10% of what was there. Not a rounding difference — a different
conclusion. And nothing in the response says so: no truncation flag, no "results were sampled" field.
You get a well-formed answer that happens to be mostly missing.

So the loop, not the query:

const out = [];
for (let h = 24; h > 0; h -= 4) {
  const from = Date.now() - h * 3600_000;
  const to   = Date.now() - (h - 4) * 3600_000;
  const ev = await queryEvents({ from, to, limit: 500 });
  if (ev.length >= 500) console.warn(`slice ${h}h hit the limit — narrow it`);
  out.push(...ev);
}

The ev.length >= 500 check matters as much as the slicing. A slice that returns exactly your limit is
truncated, and you have to narrow that slice further. Without the warning you cannot tell "500 events
happened" from "500 events fit".

Trap 3: `exists` matches empty strings, and `includes` ignores case

Two smaller ones, both of which produced confidently wrong numbers before I noticed.

operation: "exists" matches a key that is present but empty. I wanted requests Cloudflare had
identified as verified bots:

{ "key": "$workers.event.request.cf.verifiedBotCategory", "operation": "exists" }

That field is present on every request and is "" on almost all of them, so the filter matched the
entire dataset and I briefly believed the whole site was bot traffic. Use exists only for keys
genuinely absent on what you are excluding — sec-fetch-mode is a real example, since non-browsers do
not send it.

operation: "includes" is case-insensitive. Filtering user agents for bot and for Bot returned
the identical 3,181 events. Convenient once you know; misleading if you were using case to separate two
populations.

Trap 4: event counts are not invocation counts

The events view and the dashboard's invocation count disagree, and both are right. On one day my web
worker showed 24,085 telemetry events against 8,772 invocations — roughly 2.7 events per
invocation.

So:

proportions — "what share of requests were 404s", "which UA dominates" — take from the events view
absolute totals — "how many requests did this worker serve" — take from workersInvocationsAdaptive in the GraphQL analytics API, not from counting events

Mixing them gives a number that is wrong by a factor you cannot see.

What I actually run now

// Past-tense debugging: "what 500'd between 3am and 4am".
async function queryEvents({ from, to, limit = 500, filters }) {
  const r = await fetch(
    `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT}/workers/observability/telemetry/query`,
    { method: 'POST',
      headers: { Authorization: `Bearer ${TOKEN}`, 'Content-Type': 'application/json' },
      body: JSON.stringify({
        queryId: 'q', timeframe: { from, to }, limit, view: 'events',
        parameters: { datasets: ['cloudflare-workers'], filters },
      }) });
  const d = await r.json();
  return d?.result?.events?.events ?? [];
}

…called from the slicing loop above, with the results grouped in plain JavaScript rather than by asking
the API to group them. (view: "calculations" with a groupBy on a high-cardinality key returns only a
few groups, quietly — the same failure mode as trap 2: a well-formed answer that is mostly missing.)

The retention window is limited. I have reliably queried three days back and would not build a workflow
that assumes more; for anything you need to keep, pull it out and store it yourself.

One more, learned the embarrassing way: cf.asOrganization is the ASN owner, not the bot. Requests
from "Anthropic, PBC" turned out to be a crawler that robots.txt already allowed, and "Amazon
Technologies" was PerplexityBot. Identify declared crawlers by user agent; use the ASN only to catch
traffic whose user agent is lying.

The one-line version

wrangler tail is for watching. For asking, use the telemetry API — and remember that outcome: "ok"
means the worker succeeded, not that your user did, and that a query covering a wide window will hand
you a confident answer built from a tenth of the data.

The tracker this came out of is at aichangewatch.com — it watches AI
vendor docs for changes, and the 500s that started all this were a REST detail endpoint quietly falling
through to its collection endpoint.

A Missing ID Doesn't 404 — It Fetches the Whole Collection

ushiro — Tue, 18 Aug 2026 12:00:00 +0000

Keeping it running turned up a bug I think a lot of REST clients have and nobody notices, because it
doesn't look like a bug from either side.

Here it is in one line:

GET /v1/events/{id}   with an empty id

becomes

GET /v1/events/

which is not a 404. It's the list endpoint. It returns 200 OK.

What that did to my site

Every change on my site lives at a URL like:

/event/openai-gpt-4-deprecated-bf_20260723143458_0003

Slug for humans, id after the last hyphen for the lookup. The parser is exactly what you'd expect:

export function eventIdFromParam(param: string): string {
  const i = param.lastIndexOf('-');
  return i === -1 ? param : param.slice(i + 1);
}

Now consider /event/google-. A trailing hyphen, no id. Crawlers generate these. So do chat clients and
mail readers that break a long URL across lines and leave the tail behind.

lastIndexOf('-') finds the final character, slice(i + 1) returns "", and the fetch goes out as
/v1/events/.

The API answers 200 with { data: [ …every recent event… ] }.

My mapper then did what mappers do — it mapped:

if (j) return fromApi(j.data);   // j.data is an ARRAY here

fromApi read .title, .providerName, .severity off an array. All undefined. No error yet:
reading a missing property off an array is perfectly legal. The page got an object shaped like an event
whose every field was empty, rendered happily down the tree until it reached:

providerName.charAt(0)

and threw.

So the URL returned 500 where a 404 was owed. /event/google-, /event/aws-,
/ja/event/groq-groq- — all 500, live, for as long as they had existed.

Why it survived so long

Two reasons, and the second is the interesting one.

It is invisible in the request logs. I found this by querying Cloudflare's observability API for
5xx responses, and the field I would naturally have filtered on was useless:

$workers.outcome = "ok"     ← for every single one of them

A rendered 500 is a successful worker invocation. The worker ran, produced a response, returned it.
That the response was an error page is not the worker's problem. The signal lives in
$metadata.error, not in the outcome. If you filter your edge logs by outcome, application-level 500s
are simply not in your dataset.

And a sibling route accidentally hid it. The same data layer serves
/pricing/history/<slug>-<id>, and that route never 500'd. Not because it was written more carefully —
because it happens to filter:

type === 'pricing_changed'

The junk object had type: undefined, so the filter rejected it and the page 404'd correctly.
Entirely by accident.

That made the bug look route-specific. I spent time reading the event page, which was the one place
the defect wasn't.

The actual shape of the problem

It isn't the parser, and it isn't the page. It's this:

A REST detail path with a missing key silently degrades into the collection path.

/things/{id} and /things/ are different endpoints with different response shapes, and the only
thing separating them is a string you built by hand. When that string is empty, the URL you send is a
valid request for something else entirely, and it succeeds.

No status code tells you. Both are 200. Both return { data: … }. The only difference is that one
data is an object and the other is an array — and JavaScript will let you read properties off both.

The fix, and where it goes

Two guards, and it matters that they are in the data layer rather than in the page:

export async function getEvent(id: string): Promise<CWEvent | null> {
  // An empty id is a not-found, not a request.
  if (!id) return null;

  const j = await api<{ data: any }>(`/v1/events/${id}`);

  // Only a DTO that actually carries an id is an event. Anything else — a list payload,
  // `{data:null}` — is not-found, never a half-populated object handed to the renderer.
  if (j?.data?.id) return fromApi(j.data);
  if (j) return null;

  // `j === null` means the API was never reached at all (build time, or local dev with no base URL),
  // which is a different condition from "the API answered and there is no such event".
  return MOCK_EVENTS.find((e) => e.id === id) ?? null;
}

The first guard stops the malformed request being sent. The second stops a wrong-shaped response being
trusted if one arrives anyway. The third line matters for a reason worth stating: "the API said no"
and "I never reached the API" have to stay distinguishable, or a build-time render quietly turns
every page into a 404.

Putting all this in getEvent() rather than in the page component covers three call sites at once: the
page, generateMetadata, and the OpenGraph image route. Fixing it in the component would have left two
of those still 500ing, and OG image failures are especially quiet — nobody notices a missing preview
card until someone shares the link.

All four URLs are 404s now:

/event/google-                404
/event/aws-                   404
/ja/event/groq-groq-          404
/pricing/history/deepseek-    404

How to find this in your own code

The grep that would have found it for me:

# a template literal that interpolates straight into a path segment
grep -rnE '`[^`]*/\$\{[A-Za-z_]+\}`' src/

Then, for each hit, three questions:

Can that value ever be an empty string? Anything derived from a URL segment, a regex capture, a split() or a slice() can be. Mine came from lastIndexOf.
What does your API return for the collection path? If it is a 200 with a different shape, you have this bug waiting. If it 404s or 405s, you don't. This is worth one curl: curl -i https://api.example.com/v1/things/
Does your mapper verify the shape, or just read fields off it? Reading .id off an array returns undefined rather than throwing, so the failure surfaces far away from its cause — in my case several components later, on a .charAt(0).

If you own the API as well as the client, there is a fourth option that fixes it for every consumer at
once: make the collection path reject a trailing slash instead of serving the list. I didn't, because
the list endpoint is a real endpoint that real callers use — but if yours isn't, that's the cheaper fix.

The one-line version: check the id before you build the URL, and check the response carries an id
before you trust it. Neither check is clever. Both were missing.

Found 2026-08-08, fixed the same day. The tracker this came out of is at
aichangewatch.com — it watches AI vendor docs for changes, which is how it
ends up with a lot of URLs that crawlers like to truncate.

Google removed an announced Gemini 2.5 shutdown date with no changelog entry

ushiro — Thu, 13 Aug 2026 12:00:00 +0000

On July 28, Google's Gemini API deprecation page said gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite would shut down on October 16, 2026. By August 3 the date was gone. The rows now read "No shutdown date announced", and the current page shows no sign that October 16 was ever there.

I could not find the change announced anywhere — not in the Gemini API changelog, not in the release notes.

Meanwhile Google Cloud's own lifecycle page still lists all three models with a shutdown date of October 20, 2026 — four days later than the one that disappeared. Both pages are live as I write this, and they give different answers for the same three models.

That is the thread running through everything below: model lifecycle pages are not references you read once, they are data that moves — and comparing them across vendors turned out to be harder than collecting them.

I found this while crawling what 15 AI vendors publish about their own models — deprecation tables, lifecycle pages, pricing and SDK releases — and recording every time one of them changes. I had assumed tracking model deprecations would be straightforward: find the vendor's lifecycle page, extract the model name and retirement date, keep it updated.

It wasn't.

Here are some things I found while trying to make the data comparable.

1. A previously announced shutdown date can disappear

On July 28, Google's Gemini API deprecation page listed:

gemini-2.5-pro
gemini-2.5-flash
gemini-2.5-flash-lite

All three had a shutdown date of October 16, 2026, along with replacement models.

On August 3, the entries changed. Here is the gemini-2.5-pro row:

	July 28	August 3
Shutdown date	October 16, 2026	No shutdown date announced
Replacement	`gemini-3.1-pro-preview`	—
Status	deprecated	unknown

The other two rows changed the same way, each losing its own replacement (gemini-3.6-flash for gemini-2.5-flash, gemini-3.1-flash-lite for gemini-2.5-flash-lite).

The current page doesn't show that October 16 was ever announced.

There is no change history and no note saying the date was withdrawn. The only signal is the Last updated stamp at the foot of the page, which moved from 2026-07-30 UTC to 2026-08-03 UTC. It tells you that something changed, not what.

You don't have to take my word for the earlier state — the Internet Archive holds both sides:

August 2 capture (Last updated 2026-07-30 UTC): all three rows read October 16, 2026, each with a replacement.
August 4 capture (Last updated 2026-08-03 UTC): all three read No shutdown date announced, replacement column empty.

In the same table, gemini-2.5-flash-image reads October 2, 2026 in both captures. Three rows changed; the page wasn't rebuilt.

Was the change announced anywhere?

The deprecation page itself says where to look:

Deprecation announcements are made on the Release notes page, and the announced earliest shutdown dates are tracked on this page.

The Gemini API release notes are current — Last updated 2026-08-11, most recent entry July 30 — and mention neither October 16 nor its withdrawal.

There is another place to look. Google serves these same models through Google Cloud as well, where the Vertex AI documentation has moved to Gemini Enterprise Agent Platform. That lifecycle table never withdrew the date. As of August 12 it still reads:

Model	Retirement date
`gemini-2.5-pro`	October 20, 2026
`gemini-2.5-flash`	October 20, 2026
`gemini-2.5-flash-lite`	October 20, 2026

Not October 16. October 20. Archive captures of the two pages put that shift a few days ahead of the withdrawal:

Capture date	Google Cloud	Gemini API
June 10	`Not before October 16, 2026`	`October 16, 2026`
July 18–19	`October 16, 2026`	`October 16, 2026`
July 30	`October 20, 2026`	`October 16, 2026`
August 4 →	`October 20, 2026`	`No shutdown date announced`

So Google Cloud moved the date by four days, and days later the Gemini API page dropped it altogether. I could not find either change announced. The Agent Platform release notes are actively maintained — most recent entry August 4 — and don't mention it. The only announcement of October 16 I found anywhere is an April 2, 2026 entry in the old Vertex AI release notes ("The retirement dates for Gemini 2.5 Pro, Gemini 2.5 Flash-Lite, and Gemini 2.5 Flash have been updated to October 16, 2026") — on a page that now carries the banner "Vertex AI documentation is no longer being updated" and whose most recent entry is May 26.

That leaves two live answers for the same three models. Read the Gemini API docs: no shutdown date. Read Google Cloud: October 20, 2026.

Which is section 1's problem again — two platforms, two lifecycles, each page correct about its own endpoint — except this time it's one vendor. That's a defensible way to run it. It's still two answers, and neither page tells you it isn't the only one.

I noticed this because I had captured the earlier state.

That changed how I thought about the problem.

A deprecation page isn't just documentation.

It's changing data.

If you only store the current page, you can lose the fact that a vendor previously announced something.

The only way to catch it is to keep the earlier observations, not just the current page.

2. The same model gives you 3× the warning on one platform

How long do you get between "this model is going away" and "this model stops answering"?

Two vendors publish the answer as policy. Anthropic:

Anthropic notifies customers with active deployments for models with upcoming retirements, providing at least 60 days' notice before model retirement for publicly released models.

AWS Bedrock:

A model will be in the Legacy state for at least 6 months before the EOL date.

Both of them also publish the dates you need to check it. Anthropic dates each retirement announcement in its deprecation history ("On June 5, 2026, Anthropic notified developers…") and gives the retirement date in the table under it. AWS puts a Legacy date next to the EOL date.

So the notice period here is one subtraction, and both ends of it come from the vendor: start = the date the vendor says it announced the retirement (Anthropic) or moved the model to Legacy (AWS); end = the retirement or EOL date it published. No estimate, no first-seen date of my own.

	Retirements with both dates	Observed notice
Anthropic	19	60–189 days, median 63
AWS Bedrock	17 (every row)	181–185 days, median 184

Anthropic's spread is worth a second look: seven of the 19 ran 63 days, five ran 60–62, and the long tail (181, 181, 181, 189) is all from 2025. The five most recent are 60, 61, 62, 62 and 62 — the stated floor, near enough exactly.

AWS lands on six months in every single row, across five different model providers — AI21, Amazon, Anthropic, Cohere and TwelveLabs. That's a platform-wide rule, not a coincidence.

Now look at the models that appear on both:

Model	Notice from Anthropic	Notice from AWS Bedrock	Ratio
Claude Opus 4.1	61 days	184 days	3.0×
Claude Sonnet 4	62 days	183 days	3.0×
Claude 3 Haiku	60 days	184 days	3.1×
Claude 3.7 Sonnet	114 days	181 days	1.6×

Same model, same retirement, three times the runway — depending on which endpoint your code calls.

Two things before concluding that Bedrock is simply more generous.

AWS also guarantees a model stays available at least 12 months from launch, which Anthropic doesn't publish at all. But the back half of that six-month window isn't free:

During this public extended access period, active users of a Legacy model can continue to use it until the EOL date (for a minimum of 3 months), but you should expect higher pricing, which will be set by the model provider.

So part of the longer grace period is a paid extension.

And the other two vendors can't be measured. OpenAI and Google publish a shutdown date and no announcement date, so there's no start of the clock to subtract from. Google's table does carry a Release date, but that's when the model launched, not when it was marked for retirement. Whatever notice they give, their own pages don't say.

3. There is no standard "replacement model" field

Once a model is deprecated, the next question is what to migrate to. There is no common answer format.

AWS Bedrock's lifecycle table has no replacement column at all:

Model provider | Model name | Model ID | Regions | Legacy date | EOL date | Public extended access start date

It tells developers to move to the latest model before EOL, without naming a successor there.

Other vendors do provide replacement information:

Vendor	Rows checked	Rows with replacement
OpenAI	140	134 (the other 6 print "—")
Google	42 with shutdown dates	42
Anthropic	19	19
AWS	17 with EOL dates	No replacement field

This isn't necessarily a criticism of AWS. AWS hosts models from other providers, so recommending a particular successor can be a different product decision.

But the three that do publish it don't agree on where it goes.

OpenAI puts it in the deprecation table itself.

Google puts it in the deprecation table too — but only fills it in for rows that have a shutdown date. Rows marked No shutdown date announced mostly leave it empty, so "deprecated" and "scheduled" are separate states and only the second one tells you anything.

Anthropic doesn't put it in the model status table at all; that table has no such column. It's in separate tables further down the same page, one per announcement.

AWS has no field for it.

And OpenAI isn't consistent with itself: the same page uses Recommended replacement and Substitute model for the same concept. A human reads straight past that; a parser has to be told. Mine matched replacement, successor, recommended and alternative — but not substitute — so it silently lost replacement information for 26 models. The rows still had shutdown dates, so nothing looked broken; my site just showed retirements with no migration target.

That was my bug, not OpenAI's.

Four vendors, four structures, and one of them uses two inside a single document.

Update — August 15: a security fix did the same thing

On August 15, two days after this article went up, I watched the same pattern somewhere else entirely.

Claude Code v2.1.232 (August 13) listed this among its fixes:

Fixed a Windows permission bypass where Git Bash followed Cygwin-style symlinks that path validation saw as regular files; writes through them now require permission

v2.1.233, published about 23 hours later, says:

Reverted the 2.1.232 Bash permission changes for Cygwin-style symlinks on Windows and for input redirections (< file); a narrower version will return in a later release

The same release also fixes what it calls "a 2.1.232 regression" — auto mode repeatedly stopping for manual approval on ordinary cd <dir> && <command> > file commands. Which is presumably why the change was pulled: the tightening caught legitimate commands too.

Nothing here is hidden. Both lines are in the public release notes, and the revert is stated plainly.

But if you read the 2.1.232 notes on the 13th and upgraded for that specific hardening, the thing you upgraded for stopped being true on the 14th — and the only place that says so is the next release's notes, which you have no particular reason to read if you already upgraded.

Same shape as the Google case above: a published fact replaced by a later page. The differences are that the window was a day rather than a week, the vendor said so explicitly rather than silently, and it was a security fix rather than a date.

I've amended our own entry for 2.1.232 to record the revert, which is the part I'd have got wrong if I'd only read it once.

What surprised me

Before building this, I thought the difficult part would be collecting the data.

It isn't. Collecting it is a crawler and a parser.

A shutdown date can be announced and later disappear from the current page.

A model can have a different amount of notice depending on the platform.

A replacement model might be published—or not.

It might be in a different table, under a different field name, or only appear after another lifecycle state changes.

And the documentation itself changes while you're trying to monitor it.

The result is that answering a seemingly simple question—

"When does this model stop working, and what should I use instead?"

—can require multiple pages, vendor-specific parsing, and historical state.

The hard part wasn't collecting the data. It was making the data comparable.

Notes on the numbers

The numbers in this article are a snapshot taken on August 11, 2026.

Since then the AWS table has already shrunk. It listed 17 rows on August 11 and lists 13 today, because a row is removed once its EOL date passes — including the claude-3-7-sonnet row this article compares, so that one line can no longer be checked against the live page. Cohere's Command R and R+ reach EOL today, which will take it to 11. That is the article's point arriving on schedule.

The cross-vendor comparisons describe what was publicly documented at that point, not a complete historical record.

For the Google example, I have been continuously monitoring the relevant page since July 28.

I also deliberately left out figures where I couldn't distinguish between:

the vendor not publishing the information, and
my collector failing to extract it.

I've already had cases where the second explanation turned out to be true.

That was a useful lesson too.

AI Change Watch: https://aichangewatch.com/deprecations?src=devto

DEV Community: ushiro

A Model Google Lists as Shut Down Answered Me Today. Read `modelVersion` Before You Trust It.

One field says what actually happened

Before you generalise this — two things that are NOT the story

Why the narrow version still matters

Nobody has said how long this lasts

What to actually do

My CLS Was 0 Until I Throttled the Network. Then It Was 0.11.

Why an unthrottled measurement reads zero

The selector

Where that bet loses

The fix is to move the decision earlier

The rule I took from it

Two things worth keeping

Search Console Shows Your Canonical Tag. Googlebot Never Gets It.

Why grep can't see this

The cause is a design decision, not a bug

The part that cost me the most time

It only happens sometimes, and only on some routes

The fix

What this is not

My "Last Hour" Query Returned 1,252 Rows. The Real Answer Was 68.

The two halves of the comparison are different formats

Why it survived so long

Where this bug actually lives

If you can't change the format on both sides

How to find this in your own code

"Application error: a client-side exception has occurred" Is a Stale Chunk 404

The symptom

The trap: the server is fine, and that misleads you

The one request that names it

Why a redeploy does this

Two fixes, and they are not equivalent

The general shape

`No test suite found in file` on All 71 Files: Your `vite` Override Has No Upper Bound

A security override with no upper bound

Why vite 8 produced zero suites instead of an error

The fix is one character class

Then one of them failed

The second guard was also down

What I changed afterwards

A `middleware.ts` Rewrite Silently Disables ISR in Next.js 15.5

What the headers said

Why this hides so well

The cause

Two things that did not fix it

The fix

The exclusion regex has two traps

How to check it, in the order that actually works

What I still haven't proven

The iCalendar Spec Says 75 Octets, Not 75 Characters

The line that RFC 5545 actually specifies

Why counting characters isn't the only bug

The other one: your UID is not a display string

What I check now

`next dev` Renders but Nothing Works: Your CSP Is Missing `unsafe-eval`

The symptom

The one line that names it

Why this happens in dev and not in prod

Why the header reaches dev at all

Two fixes, and they are not equivalent

The general shape

Your Worker Returned 500 and the Log Says `outcome: "ok"`

The part that works

Trap 1: a rendered 500 is a successful invocation

Trap 2: a wide time window silently undercounts

Trap 3: exists matches empty strings, and includes ignores case

Trap 4: event counts are not invocation counts

What I actually run now

The one-line version

A Missing ID Doesn't 404 — It Fetches the Whole Collection

What that did to my site

Why it survived so long

The actual shape of the problem

The fix, and where it goes

How to find this in your own code

Google removed an announced Gemini 2.5 shutdown date with no changelog entry

1. A previously announced shutdown date can disappear

Was the change announced anywhere?

2. The same model gives you 3× the warning on one platform

Why `grep` can't see this

Trap 3: `exists` matches empty strings, and `includes` ignores case