DEV Community: Redlio Labs

Fixing a bad INP in React? Find the slow phase before you optimize anything

Redlio Labs — Fri, 09 Oct 2026 05:23:47 +0000

Interaction to Next Paint (INP) has been a Core Web Vital since March 2024, when it replaced First Input Delay. It's also the one teams find hardest to fix, because the usual advice ("reduce JavaScript", "use memo") is aimed at the wrong thing half the time.

INP isn't one number you can attack directly. It's the latency of a real user's slowest interactions, and each interaction's latency is made of three phases that have completely different causes. Fix the wrong phase and the score doesn't move.

So the order matters: find the interaction, find the slow phase, then pick the fix. Here's how we do that in React apps.

What INP actually measures

From web.dev's INP guide, an interaction's latency has three parts:

Input delay: from the user's tap or click until your event handlers start running. Long if the main thread is busy with something else at that moment.
Processing duration: how long your event handlers take to run.
Presentation delay: from the end of your handlers until the browser paints the next frame. Long if the update triggers heavy rendering, layout or style work.

The thresholds, at the 75th percentile of page loads:

INP	Rating
200 ms or less	Good
200–500 ms	Needs improvement
Over 500 ms	Poor

A page with a 520 ms INP might be 90 ms of input delay, 310 ms of processing and 120 ms of presentation. Memoizing components would barely touch that. Moving work out of the click handler would.

Step 1: Measure in the field, with attribution

Lab tools can tell you an interaction can be slow. Only field data tells you which interactions real users hit, on which devices. The web-vitals library's attribution build gives you the phase breakdown and the element that was interacted with:

// vitals.js
import { onINP } from "web-vitals/attribution";

onINP(({ value, rating, attribution }) => {
  const body = JSON.stringify({
    metric: "INP",
    value: Math.round(value),
    rating,
    target: attribution.interactionTarget,   // CSS selector of the element
    type: attribution.interactionType,       // "pointer" or "keyboard"
    inputDelay: Math.round(attribution.inputDelay),
    processing: Math.round(attribution.processingDuration),
    presentation: Math.round(attribution.presentationDelay),
    loadState: attribution.loadState,        // was the page still loading?
    page: location.pathname,
  });

  // sendBeacon survives the page being closed
  navigator.sendBeacon("/api/vitals", body);
});

Store those rows anywhere you can query. After a few days, group by target and look at the worst ones:

SELECT target,
       COUNT(*)                                            AS samples,
       PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY value)        AS p75_inp,
       PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY input_delay)  AS p75_input,
       PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY processing)   AS p75_processing,
       PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY presentation) AS p75_presentation
FROM   vitals
WHERE  metric = 'INP' AND created_at > now() - interval '7 days'
GROUP  BY target
ORDER  BY p75_inp DESC
LIMIT  20;

The top of that list is your worklist, and the largest of the three phase columns tells you which section below to read.

Step 2a: Input delay is high → something else owns the main thread

The user clicked, but your handler had to wait. Common causes in React apps:

Hydration. On server-rendered pages, early clicks land while React is still hydrating. If loadState in your data is mostly "dom-interactive" or "dom-content-loaded", this is it.
Third-party scripts. Chat widgets, tag managers, A/B testing and session recorders that run long tasks on load or on a timer.
Your own timers and polling that do heavy work on the main thread.

What helps:

Load third-party scripts after the page is interactive, or move them off the main thread where the vendor supports it.
Split large client bundles so less JavaScript runs during hydration. In Next.js App Router or other React Server Components setups, keep components on the server unless they need interactivity.
Break up your own long tasks (see the yield helper in the next section). web.dev defines a long task as anything over 50 ms. Every one of them is a window where a click has to wait.

Step 2b: Processing duration is high → your handler does too much

This is the most common case we see, and the easiest to fix. The handler does everything synchronously: updates the filter state, recalculates a big list, writes to localStorage, fires analytics, all before the browser is allowed to paint.

The principle: do the minimum needed for visual feedback, paint, then do the rest.

In React, that usually means marking the expensive update as non-urgent with startTransition:

import { useState, useTransition } from "react";

function ProductFilters({ products }) {
  const [query, setQuery] = useState("");
  const [visible, setVisible] = useState(products);
  const [isPending, startTransition] = useTransition();

  function onChange(e) {
    const next = e.target.value;
    setQuery(next);                 // urgent: the input must update now

    startTransition(() => {         // non-urgent: React can interrupt this
      setVisible(filterProducts(products, next));
    });
  }

  return (
    <>
      <input value={query} onChange={onChange} />
      {isPending && <span className="spinner" aria-live="polite">Updating…</span>}
      <ProductList items={visible} />
    </>
  );
}

For work that isn't a React state update (analytics, storage, logging), yield to the main thread so the browser can paint first. scheduler.yield() is built for this. It's supported in Chromium-based browsers and Firefox, but not Safari yet, so keep a fallback:

// yield.js
export function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function onAddToCart(item) {
  setCart((c) => [...c, item]);   // visible feedback first

  await yieldToMain();            // let the browser paint

  saveCartToStorage();            // then the slower, invisible work
  track("add_to_cart", { id: item.id });
}

Two more things that hide in handlers:

Large synchronous JSON.stringify / localStorage.setItem calls. Fine for small objects, slow for a whole cart or form state on every keystroke. Debounce them.
Context updates that re-render half the app. If a click updates a context value that dozens of components read, the handler's cost includes every one of those renders. Split the context or move the state down.

Step 2c: Presentation delay is high → the update is expensive to render

Your handler was quick, but the result is a lot of DOM to update, lay out and paint.

Long lists. Rendering 2,000 table rows after a filter is slow no matter how fast the filter is. Virtualize with something like TanStack Virtual or react-window, so only visible rows exist in the DOM.
Huge DOM in general. Big pages make every style and layout recalculation slower. For long content below the fold, the CSS property content-visibility: auto lets the browser skip rendering work for off-screen sections.
Layout thrashing. Reading layout (offsetHeight, getBoundingClientRect) right after writing styles forces the browser to lay out synchronously. Batch reads before writes.
Expensive CSS on elements that change often, such as large blurred shadows or filters on animated elements.

Step 3: Reproduce in the lab, then confirm in the field

Once you know the interaction and the phase, reproduce it in Chrome DevTools:

Open the Performance panel and turn on CPU throttling (4x or 6x) to approximate a mid-range phone.
Record while performing the exact interaction from your field data.
Look at the Interactions track. The interaction's bar is split into input delay, processing and presentation, and the main-thread flame chart below shows what ran in each.

Fix, re-record, compare. Then wait for the field data to catch up. Your own /api/vitals data will show the change within days. Google's Chrome UX Report uses a rolling 28-day window, so Search Console takes about a month to reflect it.

A quick checklist

[ ] web-vitals/attribution is reporting INP with phase breakdown and target
[ ] You have the top 10 worst interactions by p75, from real users
[ ] For each one, you know which of the three phases dominates
[ ] Input delay → third parties deferred, hydration work reduced, long tasks split
[ ] Processing → visual update first, startTransition or yieldToMain() for the rest
[ ] Presentation → long lists virtualized, DOM size checked, no layout thrashing
[ ] Fix verified in DevTools with CPU throttling, then in field data

INP rewards a specific kind of discipline: give the user visual feedback immediately, and push everything else just after the paint. Once a team has that habit, most new features arrive with a good INP by default.

We set performance targets like these before a page is designed, as part of how we approach custom web development. It's much cheaper than finding them in Search Console six months after launch.

Your turn: which phase was the culprit in your worst INP interaction? In our experience it's processing more often than not, but we'd like to hear about the odd ones, especially third-party scripts that only misbehave on certain pages.

From the team at Redlio Labs, where we build and run web applications.

Your robots.txt might be hiding your site from ChatGPT. Here's how to check in 10 minutes

Redlio Labs — Thu, 08 Oct 2026 11:37:20 +0000

A lot of sites added this to robots.txt some time in the last two years:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: *
Disallow: /api/

That's a reasonable choice if you don't want your content used to train models. But many teams also have a CDN rule, a WAF setting or a blanket "block AI bots" switch that goes further. Without anyone deciding it, the site also disappears from AI search: ChatGPT search, Perplexity, Claude's web search.

The AI companies now run separate bots for training, for search indexing and for fetching a page when a user asks. You can treat each one differently. Most sites haven't, because the names aren't obvious.

Which bot does what

From each company's own documentation:

Company	Bot	What it's for	If you block it
OpenAI	`GPTBot`	Training data	Content shouldn't be used to train OpenAI's models
OpenAI	`OAI-SearchBot`	ChatGPT search	Not shown in ChatGPT search answers, though navigational links can still appear
OpenAI	`ChatGPT-User`	Fetches a page when a user asks	OpenAI says that because these are user-initiated, robots.txt rules may not apply
Anthropic	`ClaudeBot`	Training data	Future content excluded from training
Anthropic	`Claude-SearchBot`	Search indexing	May reduce your visibility in Claude's search results
Anthropic	`Claude-User`	Fetches a page when a user asks	Claude can't retrieve your page for that user
Google	`Google-Extended`	Gemini training and grounding	Google says it does not affect inclusion or ranking in Google Search
Perplexity	`PerplexityBot`	Perplexity's search index	Not surfaced in Perplexity search results

Two things stand out.

Google's AI Overviews aren't on the list. They're built from the normal Search index, which Googlebot crawls. Google-Extended controls Gemini training and grounding, not whether you appear in AI Overviews. Blocking Googlebot to stay out of AI Overviews takes you out of Search entirely.

Training and search are separate switches. OpenAI's documentation says it plainly: a site can allow OAI-SearchBot to appear in search results while disallowing GPTBot to keep its content out of training.

A robots.txt that keeps you in AI search but out of training

If that's the trade-off you want:

# Search and user-requested fetches: allowed
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
Disallow: /api/
Disallow: /admin/
Allow: /

# Model training: blocked
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
Disallow: /

# Everyone else
User-agent: *
Disallow: /api/
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

One easy mistake: a crawler follows only the most specific group that matches its name and ignores User-agent: * completely. So any path you block for everyone (/api/, /admin/) has to be repeated in every named group, as above. Otherwise the named bots get access to it.

Whether to block training is a business decision, not a technical one. Some companies want their documentation in training data so that models describe their product correctly. The point is to make the choice on purpose.

Test it with a script, not by reading it

Reading robots.txt by eye is how the mistake above survives code review. Python's standard library can parse it:

# check_robots.py
from urllib.robotparser import RobotFileParser

SITE = "https://example.com"
BOTS = [
    "GPTBot", "OAI-SearchBot", "ChatGPT-User",
    "ClaudeBot", "Claude-SearchBot", "Claude-User",
    "Google-Extended", "PerplexityBot", "Googlebot", "Bingbot",
]
PATHS = ["/", "/blog/", "/pricing", "/api/health", "/admin/"]

rp = RobotFileParser(f"{SITE}/robots.txt")
rp.read()

width = max(map(len, BOTS))
print(" " * width, *[p.ljust(12) for p in PATHS])
for bot in BOTS:
    row = ["allow".ljust(12) if rp.can_fetch(bot, SITE + p) else "BLOCK".ljust(12) for p in PATHS]
    print(bot.ljust(width), *row)

Here's what it printed for our own site, redliolabs.com:

                 /            /insights/   /services/   /contact
GPTBot           allow        allow        allow        allow
OAI-SearchBot    allow        allow        allow        allow
ChatGPT-User     allow        allow        allow        allow
ClaudeBot        allow        allow        allow        allow
Claude-SearchBot allow        allow        allow        allow
Claude-User      allow        allow        allow        allow
Google-Extended  allow        allow        allow        allow
PerplexityBot    allow        allow        allow        allow
Googlebot        allow        allow        allow        allow
Bingbot          allow        allow        allow        allow

Every bot can reach every page, training crawlers included, because our file is a single User-agent: * / Allow: /. Seeing it as a grid turns that into a decision you can look at, not a default nobody remembers making. If your grid has a BLOCK you didn't expect, start there.

Put it in CI, with the expected grid committed alongside it, so a change to robots.txt that flips a cell fails the build.

(urllib.robotparser follows the original robots.txt rules. It applies the first rule that matches, while Google applies the most specific one, which is why the Disallow lines above come before Allow: /: the file then reads the same both ways. It also doesn't support * and $ wildcards in paths, so keep the file simple or test wildcard rules separately.)

Then check the layer robots.txt can't see

robots.txt is a request. Your CDN, WAF or bot-management settings are what actually answer. A request can be blocked there before robots.txt is ever consulted. Check two things.

1. What your server returns to each user agent:

for ua in "OAI-SearchBot/1.4" "Claude-SearchBot" "PerplexityBot" "GPTBot/1.4"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" -A "Mozilla/5.0 (compatible; $ua)" https://example.com/blog/)
  echo "$ua -> $code"
done

A 403 or a challenge page means something other than robots.txt is deciding. This only tests rules based on the user-agent header. Some bot-management products also verify the bot's IP ranges, which a spoofed curl can't reproduce. OpenAI publishes its crawlers' IP ranges if you need to allow-list them.

2. Whether the bots actually reach you. Your access logs are the ground truth:

grep -Eo "OAI-SearchBot|ChatGPT-User|GPTBot|Claude-SearchBot|Claude-User|ClaudeBot|PerplexityBot" access.log \
  | sort | uniq -c | sort -rn

If a search bot you allowed never appears, or only ever gets 403s, the block is upstream of robots.txt.

What this doesn't do

Allowing the search bots makes you eligible to be cited. It doesn't make anyone cite you. That depends on whether your pages answer the questions people ask, with specifics a summary can't replace. That's a content problem, not a configuration one. But it's worth fixing the configuration first, because no amount of good content helps if the crawler gets a 403.

If you're trying to work out which agencies or tools are worth paying for here, we wrote a guide to choosing a GEO agency, including the claims to be sceptical of.

Over to you: run the script on your own site and post the grid in the comments, especially if a cell surprised you. We're curious how many sites block AI search without meaning to.

From the team at Redlio Labs, where we build software and run SEO and AI search for B2B companies.

Replacing a legacy system? Run the new code in its shadow first

Redlio Labs — Thu, 08 Oct 2026 11:35:54 +0000

Most rewrites of a working system fail the same way. The new code passes every test the team thought of, goes live, and then meets the rules nobody wrote down: the discount that only applies on the last day of the month, the customer whose IDs start with a zero, the rounding the old system did "wrong" for fifteen years that finance now depends on.

You can't write tests for rules you don't know exist. But you can make the old system tell you about them. Run the new code alongside the old one on real traffic, compare every output, and treat each difference as either a bug in the new code or an undocumented rule in the old one.

This is the pattern we use when we replace parts of a legacy system. It works with the strangler fig approach Martin Fowler described, where a routing layer sits in front of the old system and parts move to new code one at a time.

The shape of it

            ┌──────────────► legacy  ──► response to the user
request ──► router
            └──(async copy)─► new code ──► compared, then thrown away

The user only ever gets the legacy response. The new code runs "in the shadow": same input, output recorded and compared, never returned. Nothing changes for users until the outputs match.

1. A shadow call that can't hurt the real request

// shadow.ts
import { compare } from "./compare";

export async function withShadow<T>(
  name: string,
  input: unknown,
  legacy: () => Promise<T>,
  candidate: () => Promise<T>,
): Promise<T> {
  const result = await legacy(); // the user always gets this

  // Fire and forget: the shadow must never slow down or break the request.
  setImmediate(async () => {
    const started = Date.now();
    try {
      const shadow = await withTimeout(candidate(), 2000);
      const diff = compare(result, shadow);
      await recordRun({ name, input, match: diff.length === 0, diff, ms: Date.now() - started });
    } catch (err) {
      await recordRun({ name, input, match: false, error: String(err), ms: Date.now() - started });
    }
  });

  return result;
}

Three rules keep this safe:

The user path never waits for the shadow. If the new code hangs, the timeout and setImmediate keep it out of the request.
The shadow must not write. Point the new code at a read-only replica, or give it a "dry run" flag that skips writes, emails, payments and webhooks. A shadow that sends a second invoice email is worse than no shadow.
Sample if traffic is heavy. Shadowing 5 to 10% of requests is usually enough to find the rare cases within a few weeks.

2. Compare meaningfully, not byte for byte

A raw comparison drowns you in noise: timestamps, generated IDs, key order, 2.50 against 2.5. Normalise before comparing, and be explicit about what you ignore.

// compare.ts
import { diff as deepDiff } from "deep-diff";

const IGNORE = new Set(["generatedAt", "requestId", "traceId"]);

function normalise(value: any): any {
  if (Array.isArray(value)) return value.map(normalise);
  if (value && typeof value === "object") {
    return Object.fromEntries(
      Object.keys(value)
        .filter((k) => !IGNORE.has(k))
        .sort()
        .map((k) => [k, normalise(value[k])]),
    );
  }
  if (typeof value === "number") return Math.round(value * 100) / 100; // money to 2 dp
  if (typeof value === "string") return value.trim();
  return value;
}

export function compare(a: unknown, b: unknown) {
  return deepDiff(normalise(a), normalise(b)) ?? [];
}

Keep the ignore list short and reviewed. Every field on it is a field you've decided not to check, so each one deserves a comment saying why.

3. Turn the differences into a worklist

Store each run with its input, the diff and a match flag. Then group the mismatches by the path that differs:

SELECT name,
       diff_path,
       COUNT(*)            AS runs,
       MIN(input::text)    AS example_input
FROM   shadow_runs
WHERE  match = false
  AND  created_at > now() - interval '7 days'
GROUP  BY name, diff_path
ORDER  BY runs DESC;

Each row is a question for the team. Is the new code wrong, or is the old system doing something nobody wrote down? Either answer is valuable. In our experience the second kind is the reason the shadow phase exists: those rules get written down and tested, so the next person doesn't have to find them the hard way.

Decide in advance which system wins when they disagree. Usually the legacy output is treated as correct until someone shows it's a bug. Otherwise every mismatch becomes an argument.

4. Define "done" before you start

Without an exit rule, shadow runs go on forever. Agree the criteria for each slice up front, for example:

Match rate of at least 99.9% on normalised outputs over the last N weeks, with every remaining mismatch explained.
Coverage of the calendar. The shadow has run through at least one month-end, and a quarter-end if the slice touches finance. Month-end is where the undocumented rules live.
Latency of the new code within an agreed margin of the old.
A rollback you've actually rehearsed, not one that exists only in a runbook.

5. Then move users gradually

When a slice meets its criteria, flip the router for a small group first:

const useNew = flags.isEnabled("orders.new-pricing", {
  tenantId: req.user.tenantId,
  region: req.user.region,
});

const price = useNew
  ? await newPricing(order)
  : await withShadow("pricing", order, () => legacyPricing(order), () => newPricing(order));

Start with one branch, region or internal team, watch the same metrics, then widen. Keep shadowing the users who are still on the old path, so you go on comparing until the last of them moves over.

Only switch the old code path off once nothing has called it for an agreed period. Then delete it, so nobody routes to it by accident a year later.

Tools that help

GitHub's Scientist library (Ruby, with ports to other languages) packages this "run both, compare, return the old result" pattern for code-level refactors.
Traffic mirroring in proxies and service meshes (for example Envoy's request mirroring, or the mirror directive in NGINX) can copy requests at the network layer when the two systems are separate services. You still need your own comparison step.
Feature flags for the gradual switch, so moving a group back takes seconds, not a deployment.

The cost of skipping it

Shadow running adds weeks to a migration, and that's the main objection. The alternative is finding the undocumented rules in production, through customer complaints and a month-end close that doesn't balance.

We wrote up the rest of the approach, from the routing layer to the cutover, in legacy modernization without downtime.

Your turn: what's the strangest undocumented rule a legacy system taught you? Month-end logic is the usual suspect, but there's always something new.

From the team at Redlio Labs, where we modernize and run business systems.

Your multi-tenant SaaS needs a test that tries to leak data

Redlio Labs — Thu, 08 Oct 2026 11:28:30 +0000

Most multi-tenant SaaS products keep customers apart with one line of code repeated a few hundred times:

const invoice = await db.invoice.findFirst({
  where: { id: req.params.id, tenantId: req.user.tenantId },
});

That works until someone writes the query without the tenantId. It might be a new endpoint, an export job, or a "quick" admin route. Nothing fails. The tests pass, because the tests only ever log in as one tenant. Then one customer sees another customer's invoice.

AWS's whitepaper on SaaS tenant isolation puts the stakes plainly: crossing the tenant boundary "in any form would represent a significant and potentially un-recoverable event for a SaaS business." The same class of bug sits at the top of the OWASP API Security Top 10 (2023) as API1: Broken Object Level Authorization.

The fix that holds up is boring: write tests whose only job is to try to read another tenant's data, and run them on every release. Below is the setup we use, in TypeScript with Jest and Supertest, plus Postgres row-level security as a second line of defence.

1. Seed two tenants with the same shape of data

Each cross-tenant test needs a victim. Seed two tenants that each own one of every resource type.

// test/fixtures/tenants.ts
export async function seedTwoTenants(db: Db) {
  const a = await db.tenant.create({ data: { name: "Tenant A" } });
  const b = await db.tenant.create({ data: { name: "Tenant B" } });

  const userA = await createUser(db, a.id, "alice@a.test");
  const userB = await createUser(db, b.id, "bob@b.test");

  // One of every resource for tenant B: the data we will try to steal.
  const bData = {
    invoiceId: (await db.invoice.create({ data: { tenantId: b.id, total: 100 } })).id,
    projectId: (await db.project.create({ data: { tenantId: b.id, name: "B project" } })).id,
    fileId: (await db.file.create({ data: { tenantId: b.id, key: `${b.id}/report.pdf` } })).id,
  };

  return { a, b, userA, userB, bData };
}

2. List every route that takes an ID, in one place

The test is only as good as its coverage. Generate the list from your router if you can. If you can't, keep it as a table in the test file. The test then fails when someone adds a route and forgets to add it here.

// test/cross-tenant.routes.ts
export const idRoutes = (ids: Record<string, string>) => [
  { method: "get",    path: `/api/invoices/${ids.invoiceId}` },
  { method: "get",    path: `/api/invoices/${ids.invoiceId}/pdf` },
  { method: "get",    path: `/api/projects/${ids.projectId}` },
  { method: "get",    path: `/api/files/${ids.fileId}/download` },
  // Writes last, so a leaking DELETE can't hide a leaking GET.
  { method: "patch",  path: `/api/invoices/${ids.invoiceId}`, body: { total: 1 } },
  { method: "delete", path: `/api/invoices/${ids.invoiceId}` },
];

3. Sign in as tenant A and attack tenant B

// test/cross-tenant.test.ts
import request from "supertest";
import { app } from "../src/app";
import { seedTwoTenants } from "./fixtures/tenants";
import { idRoutes } from "./cross-tenant.routes";

describe("cross-tenant access", () => {
  let ctx: Awaited<ReturnType<typeof seedTwoTenants>>;
  let tokenA: string;

  beforeAll(async () => {
    ctx = await seedTwoTenants(db);
    tokenA = await loginAs(ctx.userA);
  });

  test("no ID route is reachable from another tenant", async () => {
    const leaks: string[] = [];

    for (const { method, path, body } of idRoutes(ctx.bData)) {
      const res = await (request(app) as any)[method](path)
        .set("Authorization", `Bearer ${tokenA}`)
        .send(body ?? {});

      // 404, not 403: a 403 confirms the record exists.
      const bodyLeaks = JSON.stringify(res.body).includes(ctx.b.id);
      if (res.status !== 404 || bodyLeaks) {
        leaks.push(`${method.toUpperCase()} ${path} -> ${res.status}`);
      }
    }

    // One failure message listing every leaking route, not just the first.
    expect(leaks).toEqual([]);
  });

  test("list endpoints never return another tenant's rows", async () => {
    const res = await request(app)
      .get("/api/invoices?limit=1000")
      .set("Authorization", `Bearer ${tokenA}`);

    const tenantIds = new Set(res.body.items.map((i: any) => i.tenantId));
    expect([...tenantIds]).toEqual([ctx.a.id]);
  });
});

Three details matter here:

Expect 404, not 403. A 403 tells an attacker that invoice 8f2c… exists, which is still a leak.
Check the body as well as the status. Some bugs return 200 with an empty-looking object that still includes the other tenant's tenantId or a signed file URL.
Put writes last. If a DELETE leaks, it removes the record, and every later read returns 404 and looks like a pass. That's why the route list ends with PATCH and DELETE.

4. Cover the places tests usually miss

Leaks between tenants rarely come from the main CRUD routes. They come from the code paths that run without a request:

Background jobs and queues. A job payload that carries invoiceId but not tenantId, then loads the record without a tenant filter.
Caches. A cache key like invoice:${id} instead of tenant:${tenantId}:invoice:${id}.
Search indexes. One shared index queried without a tenant filter.
File storage. Object keys without the tenant prefix, or signed URLs that live for days.
Exports and reports. CSV exports built from raw SQL that skips the ORM's tenant scoping.
Admin and support tools. "Impersonate user" features that forget to switch the tenant context back.

Add at least one test per category: enqueue a job as tenant A with tenant B's ID, and assert it fails or does nothing.

5. Add a database backstop with row-level security

Tests catch the bugs you thought of. Postgres row-level security catches the query someone writes next year. With RLS on, a query that forgets the tenant filter returns nothing instead of everything.

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
-- Without FORCE, the table owner (often your app's DB user) bypasses RLS.
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

Set the tenant at the start of every transaction, from the authenticated user, never from a request parameter:

await db.$transaction(async (tx) => {
  // `true` makes the setting local to this transaction,
  // so a pooled connection can't carry it into the next request.
  await tx.$executeRaw`SELECT set_config('app.tenant_id', ${tenantId}, true)`;
  return handler(tx);
});

A few things to know before you rely on it:

Superusers and roles with BYPASSRLS ignore policies, so connect the app as an ordinary role.
If app.tenant_id is never set, current_setting raises an error, which is what you want. Don't "fix" it with a default.
Migrations and genuine cross-tenant jobs (billing runs, for example) need a separate role, and that role should be rare and logged.

Then add one test that proves the backstop works: run a raw query without the tenant filter inside a tenant-A transaction, and assert it returns only tenant A's rows.

6. Make it a release gate

Put the cross-tenant suite in CI as its own job, and fail the build if it fails. Not a nightly run, not "we'll look at it". If it's slow, run the full route list on the main branch and a smoke subset on pull requests.

It's also the evidence enterprise buyers ask for. Security questionnaires usually include some version of "how do you prevent one customer accessing another's data?". "We have a cross-tenant test suite that runs on every release, and RLS at the database layer" is a far better answer than "we're careful".

Where this fits

Isolation is one of a handful of costs that show up after the MVP, alongside billing, tax, enterprise security reviews and uptime. We wrote up the rest, with sources, in SaaS development cost: the decisions that set the number.

The short version for isolation: pick your model (separate databases, shared tables with a tenant column, or a mix) deliberately, because it's expensive to change later. Then write the test that tries to break it.

Your turn: where have you found a cross-tenant leak that the main routes didn't have? Jobs, caches and exports are the usual suspects, but we'd like to hear the odd ones.

From the team at Redlio Labs, where we build and run SaaS products.