DEV Community

Reject Duplicate JSON Keys Before Validating a Record

TokenPeak — Sun, 01 Nov 2026 13:00:00 +0000

AI and affiliation disclosure: An AI agent prepared this standalone technical article for TokenPeak. The inputs are invented teaching fixtures. Its Python examples were checked locally; no remote API, customer payload, or production parser was tested.

Consider a small JSON document containing the same member name twice:

{"decision": "review", "decision": "send"}

If your application validates only the dictionary produced by its decoder, the repeated name may already have disappeared. A check that the final value belongs to an allowed set cannot recover the ambiguity in the original document.

The Python 3.12 JSON documentation describes the default decoder's handling of repeated names and its hooks for customizing object decoding. For a record format that requires unique names, inspect the pairs while decoding instead of inspecting only the resulting dictionary.

Define a deliberately narrow input boundary

This teaching parser accepts a supplied string of at most 4,096 UTF-8 bytes and requires a top-level object. It rejects repeated member names, including inside nested objects. It also rejects the non-finite constant spellings accepted by Python's default decoder.

Decimal fractions become Decimal values so that a large finite exponent is not silently converted into a floating-point infinity. That is a representation choice, not permission to accept arbitrary numeric ranges in an application schema.

import json
from decimal import Decimal


def unique_object(pairs):
    result = {}
    for key, value in pairs:
        if key in result:
            raise ValueError("Duplicate object member")
        result[key] = value
    return result


def reject_constant(text):
    raise ValueError("Non-finite JSON constant")


def decode_record(text):
    if type(text) is not str:
        raise TypeError("Supply decoded text")
    if len(text.encode("utf-8")) > 4096:
        raise ValueError("Teaching input limit exceeded")
    value = json.loads(
        text,
        object_pairs_hook=unique_object,
        parse_constant=reject_constant,
        parse_float=Decimal,
    )
    if type(value) is not dict:
        raise ValueError("Top-level object required")
    return value


if __name__ == "__main__":
    assert decode_record('{"decision":"review"}') == {"decision": "review"}
    assert decode_record('{"amount":0.1}')["amount"] == Decimal("0.1")
    bad_inputs = [
        '{"decision":"review","decision":"send"}',
        '{"nested":{"x":1,"x":2}}',
        '{"x":NaN}',
        '[1,2]',
    ]
    for text in bad_inputs:
        try:
            decode_record(text)
        except ValueError:
            pass
        else:
            raise AssertionError("Expected rejection")
    print("6 local cases passed")

Save this block as decode_record.py and run it with Python without optimization flags, which can disable assertions. The exact block was run during preparation on Python 3.12.14. Its six cases exercise accepted objects, decimal representation, duplicate detection, non-finite constants, and the root-type rule.

Check ambiguity before business meaning

The object hook receives the member pairs before this function constructs its dictionary. Each nested object goes through the same hook. A repeated x in a child object is therefore rejected even when the outer object has unique names.

After this boundary, application validation still has work to do. The parser accepts an object with a single decision value of "launch spacecraft"; it does not define the business vocabulary. It also does not establish whether an integer is a valid identifier or whether a decimal lies within an allowed range.

Keep those stages separate in tests. One test can ask whether the document is unambiguous under your decoding policy. Another can ask whether the decoded record satisfies your domain contract. Their failure messages can then tell the caller which decision failed.

State what the size check cannot guarantee

The string already exists in memory before this function checks its encoded length. This is not a bounded network reader. It does not impose a nesting-depth limit, a numeric-digit policy, or a total CPU budget. A production boundary needs limits appropriate to its transport and parser.

The function deliberately raises an error without echoing the entire input. That keeps this particular exception message small; it is not a comprehensive logging or secret-redaction guarantee.

The practical lesson is about preserving a validation opportunity. Once decoding has collapsed repeated names into one dictionary entry, a later schema check may be too late to ask whether the original document supplied one answer or several competing answers.

Security, safety, robustness and privacy are four different problems

Ajitkumar Singh — Sun, 01 Nov 2026 13:00:00 +0000

Teams often file every AI risk under one word, usually "security" or "safety", and then argue about whether a guardrail has dealt with it. The four concerns are related, but they ask different questions, need different evidence, and usually belong to different people.

Security asks whether an actor can violate confidentiality, integrity, availability or authorized control.
Safety asks whether operating the system can cause unacceptable harm, including harm with no attacker involved.
Robustness asks whether behavior stays acceptable under noise, distribution shift, ambiguity or stress.
Privacy asks whether personal or sensitive information is collected, inferred, used, retained or disclosed appropriately.

One summarizer, three different failures

Take a model that summarizes clinical documents.

A malicious document instructs it to reveal another patient's record. That is a security attack, with privacy impact. A faithful summary leaves out a critical allergy because the scan was poor. That is a robustness failure, with safety impact. And a correct diagnosis, inferred where nobody authorized the inference, can be a privacy and governance failure with no attacker anywhere.

No single guardrail can prove all three cases are controlled. Treating the four words as synonyms produces controls too vague to test.

Different questions need different evidence

Question	Discipline	Representative evidence
Can an untrusted document cause an unauthorized tool action?	Security	Taint-aware attack tests, policy decisions, egress and tool traces
Can an allowed answer create unacceptable physical or social harm?	Safety	Hazard analysis, scenario tests, review and escalation outcomes
Does quality hold under blur, accent, long context or missing data?	Robustness	Slice metrics, perturbation tests, calibrated abstention
Can training or inference expose a person's data?	Privacy	Data inventory, minimization, access logs, deletion and privacy attack tests

Engineering Insight

Record the overlap, but keep accountability separate. Security may own exploitability and access controls, product safety the hazardous outcomes, privacy the lawful processing and minimization, and ML engineering the robustness. A shared risk register shows where they intersect; each claim in it still needs an owner, a test, a threshold and a response.

An architecture review that lists one "AI risk" control and calls the job done has usually tested one of these four. Asking which discipline a control serves, and what evidence would show it failing, is the quickest way to find the other three.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: Separate Security, Safety, Robustness, and Privacy.

Why I built a YouTube timeline with no recommendations

KH — Sun, 01 Nov 2026 13:00:00 +0000

TL;DR

I'd open YouTube to watch one video and lose an hour following recommendations. I never really tried to fight it.

So I built a page that shows only new uploads from the channels I pick, in upload order, with no recommendations and no Shorts.

Now I watch what's new and close the tab. That was the whole goal, and it works.

Plainfeed shows new videos from the YouTube channels you choose, in the order they were posted, without recommendations or Shorts. My last post was about running it on 10,000 API units a day. This one is about why it exists. It's short.

Where the time went

Nothing dramatic. I'd have a video in mind, open YouTube, watch it, click the one next to it, go back to the home page, find another one. After a while I'd be deep into videos that had nothing to do with why I came. The problem wasn't that the algorithm picked badly. It picked well.

The subscriptions tab didn't fix it either. Watching new uploads from the top, one by one, worked fine, but once I got to the end, autoplay would queue up videos from channels I didn't follow. Right when I thought I was done, the recommendations came in through the back door. Shorts were mixed in along the way, too.

A lot of people seem to have the same problem. A post I read recently on a community forum described opening YouTube for one long video and forgetting about it because of Shorts and thumbnails. The question was whether any habit or software could help.

What I didn't try

Honestly, I didn't try the usual fixes. Deleting the app, turning off notifications, installing a screen-time extension. They all felt like a fight I'd have to win every single time. The temptation stays on the screen; only my willpower changes.

I figured if the temptation wasn't on the screen, there'd be nothing to fight. YouTube without recommendations. That was the whole idea.

What I built instead

In short: I put time where the recommendations used to be.

Only new uploads from channels I pick, stacked in upload order. Nobody chose the order; the clock did.
Shorts are filtered out. Watched videos change their marker and can be hidden, so the list empties as you go. When it's empty, you're done.
No "up next" beside the player. When a video ends, there's nothing to do. That's on purpose.
No sign-in. Paste a channel URL and it works.

The key was a list with an end. A recommendation feed has no end, so there's no natural point to stop. New uploads from the channels you follow are a handful a day, and once you've seen them, closing the tab is the obvious next move.

What surprised me

I didn't expect so many Shorts. Of the 590 most recent videos across my 40 channels, 153 were Shorts, about 26% (October 2026, measured for my last post). Channels I thought of as long-form were posting Shorts in between. Filtering them out made the list noticeably shorter, which means I reach "all caught up" sooner.

What I didn't build

No screen-time limits or timers. Watch as much as you want; just don't get dragged along.
No attempt at "better recommendations." The goal was to remove them, not improve them.
It's not a YouTube replacement. If I want to search or browse, I go to YouTube. This is one window for new uploads from channels I follow.

Closing

I'm happy with it. I open it, watch what's new from the channels I care about, and close it. Not a big life change, but I no longer forget what I came for.

Next post goes back to the technical side: running this on a single Cloudflare free plan while making sure one person can't burn through D1's daily read and write limits.

Eight entries in one content array, 1,041 to 2,034 words each, and the optional field that has exactly one user

Daniel Pertu — Sun, 01 Nov 2026 12:59:38 +0000

Munchable covers eight digestive conditions, and each one has a guide page. All eight are entries in a single array of a single interface, server-rendered at build time, so the index and every guide under it come out of one file.

That makes them comparable, which is the only reason this post exists. Content you can measure against itself tells you things that content in a CMS never will.

The inventory

I counted the source entries and then counted the live pages. Sorted by the live word count:

guide                      src lines  sections  FAQs   words   links in HTML   answers linking in
coeliac disease                   87         4     5   2,034         125                88
bile acid malabsorption           54         3     3   1,543         103                67
low FODMAP and IBS                55         3     3   1,338         100                64
lactose intolerance               47         2     3   1,257          88                52
SIBO                              41         2     2   1,168         100                64
IBD                               49         3     2   1,126          84                48
GERD and reflux                   51         3     2   1,075          80                44
gastroparesis                     44         2     2   1,041          70                34

The links column counts every internal link in the page's HTML, so about 30 of each row is the header and footer that all 516 of our pages share. The last column is the number of ingredient answer pages that link back to that guide.

The top row is 95 per cent longer than the bottom row. It has twice as many source lines, twice as many sections, and more than twice the FAQ entries. It was also the last one written, which is the part that matters, because nothing in the type or the tests asked it to be bigger. It is bigger because it was written on a day when we knew more about writing these than we did for the first one.

The other seven do not form any pattern at all. They are not ordered by how common the condition is, or by how old the page is, or by anything else I can find. They are each as long as the afternoon they were written, which is what a content set with no floor looks like when you finally line it up.

The optional field

Here is the part of the interface that interests me:

export interface ConditionPage {
  slug: string;
  condition: ConditionId;
  name: string;
  h1: string;
  metaTitle: string;
  metaDescription: string;
  lede: string;
  summary: string;
  sections: ConditionSection[];
  checks: string[];
  faqs: { q: string; a: string }[];
  furtherReading?: {
    href: string;
    label: string;
    inline: string;
    blurb: string;
  }[];
}

Eleven required fields and one optional one. The optional one has exactly one user out of eight entries, and it was introduced by the entry that needed it: coeliac disease has head terms that are a vocabulary rather than a question, so it got a reference page of its own, and the guide needed somewhere to point at it from.

That is a perfectly reasonable thing to do, and it is also the exact mechanism by which content types rot. A required field is a question every entry has to answer. An optional field is a note that one entry had something extra to say. Add enough of them and the type describes the union of everything anybody ever wanted to publish, no single entry is ever incomplete, and nothing fails when a page is thin.

The alternative shape would be a separate registry keyed by condition, which makes the asymmetry visible in a file of its own rather than invisible as an absent property. I do not think that is better here, because further reading genuinely belongs next to the guide it extends. But it is worth naming the trade, because "make it optional" is the default move and it has a cost that arrives later, in a column of numbers like the one above.

The thinnest page is also the least linked

Look at the last two columns together. Each of the 461 ingredient answer pages links back to the guide for its condition, so the inbound count is a property of how many ingredient questions that condition has pages for. The spread is 88 down to 34.

Those two columns are nearly the same ranking. The condition with the most to say got the longest guide and 88 internal links pointing at it. The one with the least got the shortest guide and 34. Nobody decided that, and it compounds in the wrong direction: the page most in need of help getting found has the least help, and the page that already reads best is the one the rest of the site keeps recommending.

This is the thing I would not have noticed from inside the editor. Both numbers look fine on their own. It is only when you print them in the same table that you see the site has a quiet preference.

What a floor would actually look like

The temptation is a word count minimum, and it is a trap. A test that fails under 1,200 words produces 1,200 words, and the last 160 of them will be padding that makes the page worse.

A structural floor is defensible: every guide has at least three sections and at least three FAQ entries. Those are not quality, but they are shape, and shape is the thing that drifted. We already enforce an upper bound on the other end, a title and description budget read out of the source files by a test, so the machinery for this exists and is one assertion long.

The real remedy is not a test, though. It is going back to the first seven pages with what we learned writing the eighth. The useful output of an audit like this is not a CI rule. It is a list, in order, of which page to fix first, and that list is just the table above read from the bottom up.

If you want to see the two ends of it, the longest is the coeliac guide and the shortest is the gastroparesis one. Same template, same type, same build, 993 words apart.

I Didn't Hack This Box, I Just Pressed Ctrl+U — CyberHeroes (TryHackMe)

Farhan Hussain — Sun, 01 Nov 2026 12:58:14 +0000

Platform: TryHackMe · Difficulty: Easy · Category: Client-Side Authentication Anti-Pattern

Introduction

No exploit. No payload. No shell. The entire "challenge" lives in a browser's View Source and it took longer to write this sentence than it took to solve the box. That sounds like a joke, but it's actually the most important lesson in this whole series: if your authentication logic runs in the browser, it's not authentication, it's a suggestion the attacker is free to ignore.

CyberHeroes has the audacity to call itself a challenge while leaving its front door not just unlocked, but labelled "FRONT DOOR" in neon letters. It's a single-page portfolio site with a login form that genuinely believes security is a server-side problem. Spoiler: they didn't check with the server. If this box were a bank, the vault combination would be written on the outside of the vault in permanent marker. It's that kind of day.

Recon

Same opening move as always — RustScan for speed, Nmap for detail.

rustscan -a 10.49.154.83 -r 1-65535 --ulimit 5000 -- -Pn -sC -sV

Port	Service	Version
22/tcp	SSH	OpenSSH 8.2p1 Ubuntu 4ubuntu0.4
80/tcp	HTTP	Apache httpd 2.4.48 (Ubuntu)

Two ports, nothing exotic. Apache 2.4.48 is not ancient like some of the others in this series — this one isn't about outdated services. The HTTP title comes back as CyberHeros : Index. Typo in the page title is always a great sign of quality software engineering.

Feroxbuster with PHP, TXT, and HTML extensions across the medium wordlist:

feroxbuster -u http://10.49.154.83/ \
  -w /usr/share/wordlists/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt \
  -x php,txt,html

# output (relevant hits only)
200  http://10.49.154.83/index.html
200  http://10.49.154.83/login.html     # ^^^ this is where the fun is
200  http://10.49.154.83/changelog.txt

(truncated — the rest was asset files: images, vendor JS/CSS, nothing actionable)

login.html is the obvious next stop. changelog.txt is worth a read — it appeared to be a generic template changelog with no sensitive information — so the login page it is.

Foothold

Authentication is supposed to be validated on the server — a system the attacker cannot directly inspect or manipulate. When a developer moves that logic into client-side JavaScript, they've handed the attacker the padlock, the key, the combination, and a handwritten note explaining how the lock works. The browser must download and execute all JavaScript to render the page — which means the attacker can read every line of it before touching a single input field.

Navigating to login.html and hitting Ctrl+U (View Source) immediately reveals the authenticate() function:

function authenticate() {
  a = document.getElementById('uname')
  b = document.getElementById('pass')
  const RevereString = str => [...str].reverse().join('');
  if (a.value=="h3ck3rBoi" & b.value==RevereString("54321@terceSrepuS")) {
    var xhttp = new XMLHttpRequest();
    xhttp.onreadystatechange = function() {
      if (this.readyState == 4 && this.status == 200) {
        document.getElementById("flag").innerHTML = this.responseText ;
        document.getElementById("todel").innerHTML = "";
        document.getElementById("rm").remove() ;
      }
    };
    xhttp.open("GET", "RandomLo0o0o0o0o0o0o0o0o0o0gpath12345_Flag_"+a.value+"_"+b.value+".txt", true);
    xhttp.send();
  }
  else {
    alert("Incorrect Password, try again.. you got this hacker !")
  }
}

Breaking this down:

Username is hardcoded in the comparison: h3ck3rBoi
Password is the string 54321@terceSrepuS passed through RevereString(), which reverses it character by character — yielding SuperSecret@12345
On success, the script constructs a GET request to a .txt file at an "obscure" path that's... right there in the source, assembled from the username and password values

The credentials, the reversal algorithm, and the flag's file path are all completely readable before submitting a single form field.

Username	Password	Where Found
`h3ck3rBoi`	`SuperSecret@12345`	`login.html` JavaScript source

Substituting the known credential values into the path template from the JS:

RandomLo0o0o0o0o0o0o0o0o0o0gpath12345_Flag_h3ck3rBoi_SuperSecret@12345.txt

This file can be fetched directly without ever touching the login form:

curl "http://10.49.154.83/RandomLo0o0o0o0o0o0o0o0o0o0gpath12345_Flag_h3ck3rBoi_SuperSecret@12345.txt"

Or simply by entering the credentials into the login form, which triggers the XHR fetch and injects the response into the page.

Shell / Access

No shell required for this challenge. Access to the flag was achieved entirely via browser interaction with the login page after reading the client-side source.

Flags

Flag	Value	Location
Challenge Flag	`flag{edb0be532c540b1a150c3a7e85d2466e}`	Fetched via XHR after login — or direct URL access

Mitigations

Vulnerability	Severity	Mitigation
Hardcoded credentials in client-side JavaScript	Critical	Move all authentication logic server-side; never compare credentials in the browser
Plaintext (reversed) password obfuscation	Critical	String reversal is not encryption — use proper server-side password hashing (bcrypt, Argon2)
Predictable flag file path assembled client-side	High	Flag delivery should be gated by a server-side session check, not a client-constructed URL

Key Takeaway

Anything that runs in the browser is readable by the user — no amount of string reversal, obfuscation, or "obscure" path names changes that. Authentication logic belongs on the server, full stop.

Room: TryHackMe — CyberHeroes

56 pages that answer the same question, 12 to 21 percent shared text, and three of them collect every related link

Daniel Pertu — Sun, 01 Nov 2026 12:57:17 +0000

CogniPrep has a page per assessment provider answering one question: can you cheat this test? 56 of them, and the answer on every single one is no.

That is the worst possible brief for a content cluster. 56 pages, one verdict, one call to action, and a vendor name as the only obvious variable. Written carelessly it is a doorway-page farm. Here is what we did instead, and the one thing we got wrong, which I only found by counting.

The rule that makes the pages different

The registry's own header comment states the decision the cluster is built on:

Whether an assessment can be cheated is a property of the instrument, not of
the company that bought it. Arctic Shores defeats a shortcut in exactly the
same way at Thales as it does at Capita, so a page per employer would be
dozens of restatements of one argument. Keying the cluster to the provider
means each page can explain a mechanism that is genuinely its own.

That is the whole trick. Key the cluster to the thing that actually varies. A page per employer would have produced 132 pages with nothing to say; a page per instrument produces 56 pages where the reason a shortcut fails is different every time, because a behavioural profile with no marks, a timed adaptive paper and a forced-choice personality inventory fail a cheater for genuinely unrelated reasons.

Each entry in the registry carries seven strings: the meta title, the description, the standfirst, the verdict line, the one-line mechanism, the hub card blurb, and the name candidates actually type into a search box. I checked all seven across all 56 entries:

field              values   distinct
metaTitle              56         56
metaDescription        56         56
intro                  56         56
verdict                56         56
defence                56         56
cardBlurb              56         56
searchName             56         56

Zero repeats in 392 strings. Meta titles run from 30 to 47 characters and not one is over 60, so none of them is truncated in a result. The page bodies are 56 separate page.tsx files, 8,911 lines in total, from 117 lines for the shortest to 271 for the longest.

Measuring it from the outside

Counting distinct strings in your own registry proves you did not copy and paste. It does not prove the published pages read as different documents, because the bodies could still be one template with the nouns swapped.

So measure the deployed HTML. Strip the tags, cut the text into overlapping eight-word windows, and intersect them pairwise:

def shingles(text, n=8):
    words = [w.lower() for w in re.findall(r"[A-Za-z']+", text)]
    return set(tuple(words[i:i+n]) for i in range(len(words) - n + 1))

Across five pages in the cluster (shl, aon, hogan, usps and train-driver), each 1,361 to 1,806 words:

aon vs hogan            15.0% of the first page's shingles
aon vs shl              20.4%
aon vs train-driver     21.3%
hogan vs usps           19.3%
train-driver vs usps    12.0%

12 to 21 percent, and the floor is the interesting number. No pair in the cluster shares fewer than 210 shingles. To find out what that floor is made of, I ran the same comparison between a cheating page and an unrelated page on the site: 162 shared shingles, with no subject matter in common at all. So 162 of the floor is the header, navigation and footer, and the remaining 48 or so is the cluster's own shared furniture, the verdict banner and the call to action. Subtract both and the bodies overlap by a few percent.

Eight words is the right window size for this. Four-word windows match on ordinary English and tell you nothing; sixteen only catch verbatim paragraphs. Eight catches a reused sentence shape, which is the thing a template produces and a writer does not.

The part we got wrong

Every page ends with three related pages, chosen by a function with a limit = 3 default:

const family = Object.values(FAMILIES).find((m) => m.includes(provider)) ?? [];

const ordered = [
  ...family.filter((p) => p !== provider),
  ...CHEATING_GUIDES.map((g) => g.provider)
    .filter((p) => p !== provider && !family.includes(p)),
];

return ordered.slice(0, limit).map((p) => BY_PROVIDER[p]).filter(Boolean);

Family first, then everything else in canonical order. The families themselves are carefully argued, with comments explaining why a given provider sits with the reasoning group rather than the speeded one. The sizes are the problem:

reasoning      30 members
dutch           9
speeded         8
gamified        4
no family       5

A 30-member family and three slots means the three slots are always the same three members. Taken across all 56 pages:

distinct related-link trios            17
pages showing shl / faa-atsa / sova    27
inbound related links to shl           29
providers never offered as related     37

Two thirds of the family sees the same trio, and 37 of the 56 pages are never recommended by any page in their own cluster. You can watch it happen:

for p in train-driver usa-hire usps hogan; do
  echo "--- $p"
  curl -s "https://cogniprep.app/cheating/$p" | grep -o 'href="/cheating/[a-z0-9-]*"'
done

train-driver offers shl, faa-atsa and sova. So does almost every other page in the reasoning family. usps and hogan, which belong to no family, get the first three entries in registry order instead, which is an even more arbitrary answer dressed up as a recommendation.

Nothing is broken. Every link is valid, every target is a real page, the typecheck is clean and the pages render. The function does exactly what it says. It just turns a 56-node graph into a star with three centres, and no test asserts anything about the shape of the output, so it went unnoticed for as long as the families stayed small.

The fix is to deal from the family rather than slicing it: order the candidates by something page-specific, rotate so each page appears in a bounded number of other pages' slots, and then assert the distribution in a test rather than the validity of the links. Checking that the links resolve was never the hard part.

Two smaller things the count turned up

The word fourteen appears three times in that file's comments, describing the cluster's size. There are 56 pages. The comments were written when 14 providers were live and they were accurate then, which is the problem with counts in prose: they are facts with no test attached. The comments that survived are the ones stating a rule rather than a number.

And the derived list is built like this:

export const CHEATING_GUIDES = ALL_PROVIDERS.map((provider) =>
  GUIDES.find((guide) => guide.provider === provider)
).filter((guide): guide is CheatingGuide => Boolean(guide));

Adding a provider without writing its guide does not fail a build. It produces one fewer page, silently, and the .filter makes the types work out perfectly. What saves us is a per-provider test asserting that the provider appears everywhere it should, which is the only reason that line is safe to keep.

If you have a cluster like this

Key it to whatever genuinely varies, and if nothing does, write one page.
Generate the metadata from one place so a canonical cannot drift, and hand-write every sentence a reader sees.
Measure the published pages, not the source: eight-word shingles against the live HTML, and expect your chrome to be the floor.
Test the shape of your internal links, not just their validity. Valid links pointing at three pages is the failure mode that looks like success.

The hub is at cogniprep.app/cheating, and the shingle script above runs against it unchanged.

Stop Hardcoding Color Variants. Relative Color Syntax Does It.

Parsa J — Sun, 01 Nov 2026 12:57:09 +0000

The PR comment was two words: "wrong blue." Not a bug report, not a reproduction — a designer scrolling through a staging build, stopping on the "Upgrade" button's hover state, and flagging it because something about it felt off against the rest of the rebrand that had shipped two weeks earlier.

They were right, and it took longer than it should have to find out why. The button's resting color matched the new brand blue exactly — that token had been updated the day the rebrand landed. Its hover color was still the old brand blue, darkened. Nobody had touched it, because nobody remembered it existed.

Five variables, one of which actually gets updated

Open almost any design system's color file and you'll find the same shape: one brand color, and a handful of hand-picked variants sitting next to it that all look derived but are actually just... more hex codes.

:root {
  --brand: #3b6fd6;
  --brand-hover: #2f58ab;      /* "a bit darker" — picked by eye, once */
  --brand-active: #244289;     /* "darker still" — same deal */
  --brand-border: #6e92e1;     /* "a bit lighter" */
  --brand-tint: rgba(59, 111, 214, 0.08); /* "faint background wash" */
}

Every one of those four extra values is somebody's good-faith attempt, at some point in the past, to eyeball a lighter or darker or more-transparent version of --brand. They're not wrong on day one. The problem shows up the day --brand changes and the other four don't — because CSS has no idea they were ever related. To the engine, --brand-hover isn't "darker --brand." It's just a string that starts with #2f58ab, full stop.

The "obvious" fix is discipline: a comment reminding whoever edits --brand to also update the other four, or a design-tokens build step that regenerates them from a single source before CSS ever sees them. Both work, right up until the person making a one-line brand tweak six months from now doesn't know the build step exists, or skims past the comment. Discipline that depends on nobody being in a hurry isn't a fix — it's a bet, and the rebrand PR is the bet losing.

The variables were never the problem — storing the relationship was

Here's the reframe that matters: --brand-hover was never really an independent color. It was always a function of --brand — "darker, same hue." --brand-tint was always "the same color, 8% opaque." The relationship was real and well understood by whoever first picked those hex codes. What got lost was that the relationship lived in a person's head for thirty seconds and then evaporated, leaving only its one-time output behind, frozen in a stylesheet forever.

What you actually want is for CSS to store the relationship, not just a snapshot of what it once produced — and that's a genuinely new category of thing for CSS to express. For most of CSS's life, a color value was a dead end: #3b6fd6 tells the renderer what to paint, but nothing about where it came from or how to get a cousin of it. color-mix() loosened that slightly — you can blend two colors — but blending two colors isn't the shape of this problem. You don't have two brand colors to mix; you have one color, and you want its lightness turned down a notch while everything else about it stays put.

Before you keep reading: what would you even call the CSS feature that lets you say "same color, just darker"? It's a fair question, because until relatively recently there wasn't a clean answer.

Relative color syntax: read a color's own channels back out

Relative color syntax lets a color function take another color as input and expose that color's own channels as variables you can do math on, right there in the function call:

:root {
  --brand: #3b6fd6;

  /* "same hue and chroma as --brand, just darker" */
  --brand-hover:  oklch(from var(--brand) calc(l - 0.12) c h);
  --brand-active: oklch(from var(--brand) calc(l - 0.20) c h);

  /* "same color, lighter, for a border" */
  --brand-border: oklch(from var(--brand) calc(l + 0.15) c h);

  /* "same color, 8% opaque" */
  --brand-tint: oklch(from var(--brand) l c h / 8%);
}

Read the oklch(from var(--brand) ...) part literally: "take --brand, convert it to OKLCH, and give me three variables back — l for lightness, c for chroma, h for hue." Whatever you write after that is just CSS math on those three numbers (plus an optional alpha after the slash). calc(l - 0.12) means "this color's own lightness, minus 0.12" — not a hardcoded lightness value, a relationship to whatever --brand happens to be right now.

Change --brand to a rebrand's new blue, or swap it entirely for a dark-mode theme, and every line below it recomputes. There's no second hex code to forget, because there is no second hex code — --brand-hover isn't stored anywhere; it's derived, every time the browser needs it, from the one variable a human actually edits.

This isn't OKLCH-only, either. rgb(), hsl(), and color() all support the same from syntax, exposing whichever channels that color space naturally has:

/* rgb()'s own channels: r, g, b (0–255), alpha */
.badge { background: rgb(from var(--brand) r g b / 15%); }

/* hsl()'s own channels: h, s, l, alpha — s and l come back as plain
   numbers (0-100), not percentages, so the math below uses 10, not 10% */
.link:hover { color: hsl(from var(--brand) h s calc(l - 10)); }

OKLCH is usually the better pick for lightness math specifically, because it's designed so that "lightness" tracks perceived brightness consistently across hues — nudging l down by the same amount darkens a yellow and a blue by roughly the same perceived amount. Nudge hsl()'s l channel the same way and the result can feel inconsistent hue to hue, because HSL's lightness was never built to model human perception in the first place.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

The one sharp edge: clamp your math

calc(l - 0.12) is honest math, which means it'll happily produce a number outside the range that makes sense. Pick a brand color that's already quite dark, subtract 0.20 from its lightness, and l can go negative — which isn't a color error so much as a "this doesn't mean anything" result, rendered as whatever the browser decides black looks like.

The fix is the same clamp() you'd reach for anywhere else in CSS, wrapped around the channel math:

--brand-hover: oklch(from var(--brand) clamp(0, calc(l - 0.12), 1) c h);

That one change makes the derivation safe for any input color, including ones your design system doesn't control yet — a user-customizable accent color, say, or a brand color read from a CMS. Skip the clamp and the formula only works for colors in roughly the lightness range you tested it against, which defeats a good chunk of the point: a derivation that only works for some inputs is just a more elaborate hardcoded value.

Is this safe to ship, or is it another flag-gated preview?

Safe to ship — but the rollout order isn't what you'd guess. Safari 16.4 (March 2023) was the earliest browser with something, but it was a partial pass at an older draft of the spec with real parsing bugs; that implementation was later replaced, not extended. Chrome and Firefox did the work of actually matching the final spec through 2024 (Firefox in Firefox 128, July 2024), and Safari didn't catch up — bug fixes included — until Safari 18 in September 2024. So for the exact forms used above, Safari was last to ship the behavior this post describes, not first. Either way, that was over two years ago: by now every major evergreen browser has unprefixed, unflagged, spec-correct support, and there's no realistic "but what about X" objection left to raise for a typical modern browser matrix. If your project still has to support browsers from before that window, the fallback is simple and honest: keep writing literal hex variants for those browsers, and layer the relative syntax on top for everyone else — it degrades to "the hardcoded value you already had," not to a broken page.

🧠 Test yourself

Think it clicked? Take the 7-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The bug wasn't really "someone forgot to update a hex code." It was that the stylesheet never had anywhere to put the fact that --brand-hover meant "darker --brand" — so that knowledge lived in a person's memory instead, with exactly the shelf life you'd expect. Relative color syntax isn't a shorter way to write the same five hex codes. It's a way to stop writing four of them at all.

Where does your own color system still keep that kind of relationship in a comment instead of in the CSS itself?

📚 Read next

🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___

Two of our pages are 1,065 and 1,083 words long, and the reading times under their titles say 6 minutes and 8 minutes

Daniel Pertu — Sun, 01 Nov 2026 12:56:36 +0000

Notifio is a desktop app that watches rental search pages and alerts you when a new listing appears. Around it is a Next.js site, and eight of that site's 38 URLs are long-form pages: five guides and three pages for a kind of person rather than a task.

They are all one type:

export type Article = {
  slug: string;
  /** Which route this belongs to. */
  kind: "audience" | "guide";
  eyebrow: string;
  title: string;
  description: string;
  h1: string;
  standfirst: string;

  /** Rough minutes, shown under the title. Keep it honest. */
  readingMinutes: number;

  sections: ArticleSection[];
  faqs: { q: string; a: string }[];
  sources: ArticleSource[];
  relatedSites: string[];
  relatedArticles: string[];
};

readingMinutes is a number a person types. There is no word count behind it, no division, nothing derived. The comment says "Keep it honest", which is the sort of instruction that deserves to be checked, so I checked it.

What the pages actually contain

Counted from the rendered <main> of each live page, which includes the body, the headings, the FAQ block and the related links, because that is what a reader scrolls through:

Page	Claimed	Words	Implied words per minute
/guides/how-fast-do-rental-listings-go	6	1,065	178
/guides/how-to-be-first-to-a-rental-listing	7	1,085	155
/guides/first-message-to-a-landlord	6	966	161
/guides/rental-documents-checklist	5	845	169
/guides/rental-scams-netherlands	6	1,172	195
/for/students	7	1,228	175
/for/expats	8	1,219	152
/for/amsterdam	8	1,083	135

The usual convention for a read-time badge is 200 to 250 words a minute. Against 200, every single one of these eight claims is longer than the page. That on its own I can live with: generous is the right direction to be wrong in, because a reader who finishes early is pleased and a reader who runs over feels misled.

The part I cannot defend is the spread. The first row and the last row are 18 words apart, 1,065 against 1,083, and their badges differ by two minutes. There is no reading speed at which both of those numbers are right. Whatever the typed figure measures, it is not length, and it is not consistent between two pages written weeks apart by the same person.

It is also not very useful information. The honest version of the field, for a page of this size, has two possible values: "about five minutes" or "about eight minutes", and the difference between the two is one scroll.

The two ways to get this wrong

A sibling codebase of mine has read times computed as a word count divided by 200, where the division is real and the word count is a number somebody typed. This one skips the arithmetic and types the answer.

They are the same bug wearing different clothes: a derived number stored as an input. Both look fine forever, because nothing can fail. A page gets two new sections, nobody updates the badge, and the badge was never checked against anything in the first place.

The fix is three lines, and it is the same three lines in both codebases:

export function readingMinutes(article: Article): number {
  const words = article.sections.flatMap((s) => [
    s.heading,
    ...s.body,
    ...(s.points ?? []).flatMap((p) => [p.title, p.body]),
  ]);
  return Math.max(1, Math.round(words.join(" ").split(/\s+/).length / 200));
}

The content is already structured data in a TypeScript file, so the word count is available at build time for free. Deleting a field from a type is a nicer change than adding a test that asserts a human typed a defensible number.

While I was in there

Three other things the same eight objects told me.

Thirty-two FAQs, exactly four per page. Not approximately four. Four, eight times. Nobody decided that a page must have four questions, and yet nobody has ever shipped one with three or five, which is the kind of pattern that forms when you copy the previous entry and fill it in. The questions are good and the uniformity is a tell: a page with only two real questions should ship two.

Five citations across eight pages. sources is part of the trust model, because the rule these pages are written against, in the type's own comment, is that "the advice has to be worth reading by somebody who never buys anything". Two pages carry two sources, one carries one, and five carry none. The layout renders the block conditionally:

{article.sources.length > 0 && (
  // ...the Sources heading and the list
)}

So five of the eight do not show an empty Sources heading, they show no heading, and nothing in the build complains. The pages with nothing to cite are the softer, advice-shaped ones, which is exactly where a citation does the most work. A test that fails a published article with zero sources is the cheap version of a standard, and it would currently fail five pages, which is the point.

One URL space, no root. Guides live at /guides/<slug> and audience pages at /for/<slug>, from one type, split by one field:

export function articleHref(article: Article): string {
  return article.kind === "audience" ? `/for/${article.slug}` : `/guides/${article.slug}`;
}

That split is deliberate and I would do it again: /guides/ is for somebody describing a task, /for/ is for somebody describing themselves, and the two read differently even when they say similar things. The consequence is that /for by itself is a 404. The hub at /guides lists both kinds and its ItemList structured data carries all eight, so nothing is unreachable, but the parent of three live URLs answering 404 is the kind of thing an SEO audit flags and a human never notices.

The link graph, which I was not expecting to be the best part

Each article links three others and three or four of the per-site alert pages. Counting inbound links across the eight:

first-message-to-a-landlord: 5
rental-scams-netherlands: 4
rental-documents-checklist, expats, amsterdam: 3 each
how-fast-do-rental-listings-go, how-to-be-first-to-a-rental-listing, students: 2 each

Twenty-four links, hand-written, no orphans, and the most-linked page is the one about what to write to a landlord, which is also the page a person actually needs at the moment they are panicking. The structure came out right because each article's relatedArticles was filled in by somebody thinking about that reader rather than about the graph.

The alert pages did less well. Twelve of the fifteen get at least one link from an article. Three get none: Huurwoningen, ImmobilienScout24 and Zoopla. Those three are reachable from the hub and the footer, so this is not the page with no sibling links problem I wrote about before, it is a weaker version of it: the pages with the fewest editorial links in are the ones whose countries the guides happen not to be about. Two of the three are the UK and Germany, and the guides lean Dutch. The fix is a guide, not a link.

If you want to read the pages rather than the measurements, they are at notifio.app/guides, the per-site setup pages are at notifio.app/alerts, and the app the whole thing is in front of is on the download page with its price on the pricing page. The reading times are under the titles. They are too high by about a minute each, and the next change to that file takes the field out.

You Have Joined a Team That Writes Code for a Device on Your Desk

Asael Shinder — Sun, 01 Nov 2026 12:56:21 +0000

For years your code has run on servers you never saw. Now you have moved to a team that builds the software inside a small device, a sensor that sits on factory machines and reports their temperature. On your first morning someone hands you a circuit board, a cable and a datasheet of two hundred pages. There is no debugger you recognise, no log viewer and no way to refresh the page.

It is tempting to start by reading everything. The datasheet, the codebase, the team's wiki, the notes from the last hardware revision. You will learn some of it, and it will all feel abstract, because you have no way yet to watch any of it happen.

Here is a better first goal. Before you try to learn how the device works, build yourself a way to see what it is doing.

In web work that comes for free. You change a line, reload, and the result is in front of you within seconds. Here you may have to make it yourself. Find out how the team gets messages out of the board, often through a serial connection to your laptop. Learn how to flash a new build and how long it takes. Ask whether there is a logic analyser or an oscilloscope in the office, and ask someone to show you how they use it. Get a light to blink when your code reaches a certain line.

That sounds trivial. It is the most important thing you will do in the first week. Once you can change something and see the effect quickly, every other kind of learning speeds up. The datasheet stops being a wall of tables and becomes a reference you check against what you can observe. Questions you would have had to ask a colleague, you can now answer by trying.

Pay attention to how the experienced people on the team watch the device. Their habits will show you which signals matter. They may have a script that decodes the raw output or a test rig that fakes a sensor reading. Ask for a copy.

The same lesson works far beyond hardware. Whenever you land somewhere unfamiliar, a new platform, a new data pipeline, a system that runs overnight, your first job is to shorten the distance between doing something and seeing what happened. Learning follows much faster after that.

– Asael Shinder

We passed null to say use the default and Terraform switched off deletion protection

Sergey Shinder — Sun, 01 Nov 2026 12:56:12 +0000

In August an engineer ran terraform destroy in what he thought was his own sandbox workspace. It was the shared QA environment, and among the things it removed was the QA database. Nobody worried at first, because our database module sets deletion_protection to true, and AWS refuses to delete an RDS instance with that flag set. The instance was gone anyway.

The platform team owns the database module, and its variable for the flag has a default of true. Most teams do not call it directly. They call a wrapper module that adds their naming and tags, and the wrapper exposes the same setting with a default of null. The intention, written in a comment in the wrapper, was simple: if a team says nothing, let the platform module decide.

That is not what null does. A variable in Terraform is nullable unless it says otherwise, and passing null into a nullable variable does not mean the caller left it out. It means the caller set it to null, and the default is never consulted. The platform module received null and handed it straight to the aws_db_instance resource, where a null argument is treated as not set at all. The provider then used its own default, which for deletion protection is false.

So every database built through the wrapper had been created without protection. Each create plan had said deletion_protection = false, one line among sixty in a module everyone trusted. AWS Config has a managed rule, rds-instance-deletion-protection-enabled, and when we finally switched it on it reported fourteen of our twenty two instances, all built through the wrapper since its first version. We restored QA from the nightly snapshot copy and lost an afternoon of test data.

Every variable in the platform module now sets nullable to false. With that set, a null coming in is replaced by the module's own default, which is the behaviour the wrapper's author had expected all along. The wrapper drops its own defaults and passes values only when a team sets them. The Config rule stays on in every account, and the database resource has a precondition that fails the plan unless the resolved value is true.

Null in Terraform means unset, and an unset value goes to whoever is next in line. Ours was a provider that had never heard of our standards.

– Sergey Shinder

Our only patched dependency spells its version in four places by hand, and the install checks three of them

Daniel Pertu — Sun, 01 Nov 2026 12:56:02 +0000

Munchable's label camera has tap to focus. You point the phone at an ingredients panel, the autofocus hunts, you tap the words and it locks on them for a few seconds before handing back to continuous focus.

expo-camera does not ship that. So the repo carries a patch, and the whole of it is two lines of config:

# pnpm-workspace.yaml
patchedDependencies:
  expo-camera@57.0.5: patches/expo-camera@57.0.5.patch

This is a post about those two lines rather than about the camera, because today I fixed a bug in them that no tool in the repository could have found.

What is in a 221-line patch

Ten files:

android/src/main/java/expo/modules/camera/CameraViewModule.kt
android/src/main/java/expo/modules/camera/ExpoCameraView.kt
ios/CameraViewModule.swift
ios/Current/CameraSessionManager.swift
ios/Current/CameraView.swift
src/Camera.types.ts
src/CameraView.tsx
build/Camera.types.d.ts
build/CameraView.d.ts
build/CameraView.js

121 added lines. The Kotlin side builds a metering action from the touch point and lets the preview's own point factory undo whatever the cover-fit crop did to the coordinates. The Swift side does the equivalent. Then the same method has to exist in JavaScript, and that is where patching a published package gets interesting, because an Expo module ships compiled output:

src/CameraView.tsx is what a person reads
build/CameraView.js is what Metro actually loads
build/CameraView.d.ts is what TypeScript believes

All three have to be in the patch. Edit only the source and the method does not exist at runtime. Edit only the build output and your own call site is a type error. This is the part people do not expect from "just patch the package": you are editing a build artefact, by hand, in a diff.

Why a patch and not a fork

A fork means publishing a package and owning its release cadence against an SDK that moves every few weeks. A config plugin cannot add a method to a view manager. A separate native module means re-implementing enough of the camera to own a preview.

The patch, by contrast, is reproducible from the lockfile, which records it by content:

# pnpm-lock.yaml
patchedDependencies:
  expo-camera@57.0.5: d3f519a89e5ff8270e755eb5497f063d085496b31906fa63a44704e6aa67275b

And that hash is not just a note. It is part of the package's identity in the resolution graph:

expo-camera@57.0.5(patch_hash=d3f519a8...)(expo@57.0.24)(react-native@0.86.3)...

Change one line of the patch and the dependency becomes a different dependency, so every machine either has the patched copy or re-fetches and re-patches. That property is the whole argument for this approach. A patch that can silently not apply would be worse than a fork.

The version number lives in four hand-written places

Count them:

apps/mobile/package.json, as the dependency range: "expo-camera": "~57.0.5"
pnpm-workspace.yaml, as the patchedDependencies key: expo-camera@57.0.5
The patch filename itself: patches/expo-camera@57.0.5.patch
A comment in apps/mobile/app/capture.tsx explaining where focusAtAsync comes from

Plus two more that pnpm generates in the lockfile, which do not count because nobody types them.

Three of those four are load-bearing, and the install is loud about all three. I tested the second one in a throwaway project rather than taking pnpm's documentation on faith: a key naming a version that is not installed, with everything else correct.

[ERR_PNPM_UNUSED_PATCH] The following patches were not used: is-odd@3.0.0

Either remove them from "patchedDependencies" or update them to match
packages in your dependencies.

Install fails. Not a warning, not a quiet skip, a non-zero exit, which is exactly what you want from a patch that adds a native method the app calls unconditionally. The filename is checked the same way: name a file that is not there and the install stops.

The fourth place is the comment, and nothing on earth checks a comment. When the dependency moved from 57.0.4 to 57.0.5, items one, two and three had to change together or the install would not complete. Item four did not have to change, so it did not, and for a while the file explaining the patch pointed at patches/expo-camera@57.0.4.patch, a path that does not exist, in the one place a new reader would go looking.

That was today's fix. One character.

The fix I did not make

The obvious response is to stop writing the version in the key. pnpm accepts a semver range, or the bare package name, and I checked both work:

patchedDependencies:
  is-odd@^3.0.0: patches/is-odd@3.0.0.patch   # applies to 3.0.1
  is-odd: patches/is-odd@3.0.0.patch          # also applies

Tempting, and wrong for this patch. An exact pin means the next expo-camera release stops the install until a human re-reads 221 lines of native diff against the new upstream code. A range means a patch written for 57.0.5 applies itself to 57.1.0 as long as the context lines still match, and "the context lines still match" is not the same statement as "the camera still focuses". For a patch made of Kotlin, Swift and a compiled JavaScript file, I want the interruption.

So the pin stays, and the conclusion goes the other way: the version number should not be in the comment at all. The comment should say that a patch exists and that pnpm-workspace.yaml names it, because that file cannot be stale. A fact with no checker, written in prose, is not documentation. It is a claim about the repository that only decays.

If you want to see what those 121 lines bought, you need the app rather than the website: munchable.app has the install link, and the tap to focus is on the label camera, the screen you reach by scanning a barcode we do not hold yet. If you want the words instead, the about page says what the camera is for.

Half of our revalidatePath calls name a layout, and a streaming campaign header is the reason

Daniel Pertu — Sun, 01 Nov 2026 12:55:30 +0000

Next.js gives you server rendering with a cache in front of it and then makes invalidation your problem. In Nakodo that problem is 46 lines long, and I had never looked at all 46 of them together until this week.

Here is the whole census.

The numbers

Ten files carry "use server", holding 62 exported actions. Six of those files call revalidatePath, 46 times in total:

$ grep -rl '"use server"' src | wc -l
10
$ grep -rc "revalidatePath(" src | grep -v ':0'
src/app/(app)/settings/actions.ts:3
src/app/(app)/support/actions.ts:6
src/app/(app)/campaigns/actions.ts:27
src/app/admin/users/actions.ts:4
src/app/admin/support/actions.ts:2
src/app/admin/mailing/actions.ts:4
$ grep -rno 'revalidatePath([^)]*)' src | grep -c '"layout"'
24
$ grep -rn "revalidateTag\|'use cache'" src | wc -l
0

So: 38 of the 62 actions invalidate something, 24 invalidate nothing at all, half of the calls pass "layout" as the second argument, and tags are not used anywhere in the codebase.

Why half of them say "layout"

Every one of the 24 "layout" calls names a campaign path, and the reason is where the campaign's header lives.

export default async function CampaignLayout({ children, params }: LayoutProps<"/campaigns/[id]">) {
  const { id } = await params;
  return (
    <div className="space-y-6">
      <div className="space-y-3">
        <Suspense fallback={<HeaderSkeleton />}>
          <CampaignHeader id={id} />
        </Suspense>
        <Suspense fallback={<CampaignTabs campaignId={id} kind={null} />}>
          <Tabs id={id} />
        </Suspense>
      </div>
      {children}
    </div>
  );
}

Only the URL is awaited in the layout itself; the header and the tab bar stream in separately, so switching tabs shows the new page's skeleton immediately instead of waiting for a header that has not changed. That is a performance decision, and it has a cache consequence: the header is not part of any page, it is part of the layout, and it holds the three things most likely to be out of date after an action.

The header renders the campaign's name and logo, its catalogue number, a live status dot, and a progress line that is either "All N keywords searched" or "M of N keywords searched". Pause a campaign and all of that changes. Approve a batch of first emails and the status word changes. Save a brief and the name can change.

revalidatePath("/campaigns/" + id) on its own invalidates the page segment and leaves the layout above it cached, so the body of the screen would update while the status beside the title still said the old thing. The second argument is not a precaution, it is the difference between a correct screen and a screen that contradicts itself.

The cost is real and I accept it: "layout" invalidates the whole subtree, so a reply to one conversation re-renders the results tab, the outreach tab and the brief tab the next time any of them is visited. Those are all dynamic, per-user pages whose data is one round trip to Postgres, so the thing I would be optimising is a few database queries nobody is waiting on. A finer-grained version of this would need tags, and tags would need a cache key per panel, and that is a lot of machinery to avoid re-running select count(*).

The 24 that invalidate nothing

Three different reasons, and all three are deliberate.

They redirect. deleteCampaignAction, changePlanAction, deleteAccountAction, sign-in, sign-up, password reset, the opt-out page. A redirect from a Server Action navigates, and every destination here is a dynamic page that renders per user on arrival, so there is nothing to invalidate. This is the one group where I would add a comment next time: the correctness depends on the destination being dynamic, and if we ever set staleTimes to keep dynamic segments in the client router cache, a deleted campaign could appear in the list it redirects to. We set no staleTimes today, so the default behaviour is on our side.

They return a suggestion, not a fact. suggestProposalAction, suggestCampaignDetailsAction, findLogoAction, checkedGuessesAction, previewUpgradeAction. These hand an answer back to an open form, which puts it in React state next to whatever the person has already typed. Invalidating the page would be worse than useless: it would re-render the server's version of a form whose client state is the one the user is editing. The write happens later, in the save action, and the save action does invalidate.

The UI already knows. acceptTermsAction is the clearest case. The terms notice records acceptance on mount and the dismiss control only hides it, so there is no server render anybody is waiting for. askSupportAction is the same shape: the answer is appended to a transcript the client holds.

The pattern across all three is that revalidatePath is for changes to what the server would say if it were asked again. If the browser is already holding the new truth, invalidating is a request to go and fetch the old screen.

The action that invalidates in both branches

try {
  ...
  if (campaign.status === "active") await queueRescore(campaignId);
  revalidatePath(`/campaigns/${campaignId}`, "layout");
  return result;
} catch (e) {
  revalidatePath(`/campaigns/${campaignId}`, "layout");
  return { ...failure(e), briefSaved: true };
}

That is the save-and-launch action, and the duplicate is the point. The brief is saved before the launch is attempted, so a failed launch still changed the campaign. Invalidating only on success would leave the screen showing the old brief next to an error message about launching it, which is the single most confusing thing a form can do. The briefSaved: true in the failure result is the other half of the same thought: the error message has to be able to say "your brief is saved, the launch is not".

The admin notice sender does the same thing four times, once at each of its four exits, because every exit writes to the progress row the page is showing. One path per exit, one call per path, no attempt at a finally, because two of those exits return early and a finally would hide which ones.

Paths that are not the page you are on

Operator actions invalidate the record they edited:

revalidatePath(`/admin/users/${userId}`);

except the one that deletes the account, which invalidates the list instead:

revalidatePath("/admin/users");

Invalidating /admin/users/<id> after deleting <id> would be asking the cache to refresh a page that will now 404. Obvious once written down, easy to get wrong when you are copying the line above.

The support actions invalidate two paths each, a computed thread path and the list:

revalidatePath(supportPath(reference));
revalidatePath("/settings/support");

because a reply changes both the conversation and its row in the list, and the list shows the last message time and an unread marker.

What revalidatePath cannot do here

Nakodo's screens change while nobody is pressing anything. Creators turn up, replies arrive, emails go out on a schedule. No Server Action ran, so no invalidation can be the mechanism. That half of the problem is solved by polling a 16-character fingerprint of what the page shows and calling router.refresh() only when it changes, which is a separate route and the subject of its own post. There are exactly four router.refresh() calls in the app, and that poll is one of them.

Which leaves one honest gap in the census. Twenty-three calls name a single campaign's subtree (18 of them by campaign id, five by the campaign a conversation belongs to), and exactly one call in the whole codebase names the campaigns list:

revalidatePath("/campaigns", "layout");

It is in the action that splits the daily email allowance between campaigns, because that one visibly changes every row at once. But pausing a campaign also changes its row in that list, and that action invalidates only the campaign's own subtree. The list is dynamic, so a fresh navigation re-renders it; a back-navigation inside the same session is the case I want to go and watch in a browser before claiming it is fine.

Forty-six calls, no tags, no "use cache", and the only thing in this census I would change is a comment on the 24 actions that deliberately do nothing. Code that is correct because of a framework default is code that needs a sentence saying so.