
# The Lint Setting That Ate 12 GB

## What I Was Working On

Our frontend is a pnpm monorepo: one main app plus a few shared libraries, run by Turborepo and built on AWS Amplify. Dependabot opens PRs to update dependencies, and six of the last seven had failed the cloud build.

## The Problem

It looked like dependency trouble, but the build never got that far. A lint process was killed with exit code 137, before type checking or the real build even started. Exit code 137 means the process got SIGKILL (a kill it can't catch). Here the kernel sent it because the 8 GiB build container ran out of memory.

## How I Found It

I measured the peak memory (RSS, the RAM a process actually holds) of each lint task. The six lint tasks run in parallel, and together they peaked at about 11.9 GB.

The cause was one line in the shared ESLint config: `parserOptions.project`. It turns on typed linting, so typescript-eslint builds a full TypeScript program for each package before ESLint can lint it. The typescript-eslint docs say typed linting is "generally as slow as type checking that same project."

That cost only pays off for rules that need types, like `no-floating-promises`. Our config had none. We were paying for type information nobody used.

So why only dependency PRs? A dependency update changes the lockfile. A lockfile change invalidates Turborepo's cache, so all six lint tasks rerun at once. That is exactly the case that ran out of memory.

## The Fix

I deleted one line from the shared ESLint config:

```diff
 parserOptions: {
   ecmaFeatures: {
     jsx: true,
   },
-  project: './tsconfig.json',
 },
```

Then I checked that nothing got weaker:

- The `naming-convention` rule still reports a bad interface name without type info.
- `tsc` still runs with `strict` on and finds 0 errors. Type checking stays `tsc`'s job.
- All six lint tasks pass with Turborepo's `--force` flag, so no result was replayed from cache.

That last point matters. Editing the lint config doesn't change Turborepo's cache key, so a plain `pnpm lint` can replay a result from the old config.

## Results

Peak memory per lint task, before and after:

| Lint task | Before | After |
|---|---|---|
| Main app | 3.20 GB | 0.62 GB |
| Each of four shared libraries | 1.99–2.37 GB | 0.28–0.45 GB |
| All six at once | 11.90 GB | 2.08 GB |

The main app's lint also ran about twice as fast. Same rules, same type checking.

## What I Learned

- **`parserOptions.project` isn't free.** It makes the linter build a TypeScript program per package. Turn it on only when a rule actually needs types.
- **Type checking is `tsc`'s job.** The linter doesn't need to do it again.
- **Ask why only some PRs fail.** These failed because they change the lockfile, which reruns every lint task at once. The new dependencies were never the problem.
- **Write down when to undo it.** I put the condition in the commit message: adding a type-aware rule means bringing the setting back, and a bigger build machine with it. Some options, like `types` on `naming-convention`, fail quietly without it instead of loudly.

## TL;DR

Dependency-update PRs kept failing our cloud build with out-of-memory errors, but the dependencies were fine. ESLint's `parserOptions.project` made typescript-eslint build a full TypeScript program for every package, about 11.9 GB across six parallel lint tasks in an 8 GiB container, while no rule used type information. Deleting that one line dropped peak lint memory to 2.08 GB and made the main app's lint about twice as fast. Type checking stays with `tsc`.

---

*Twelve gigabytes of type information, and not one rule asked for it.*


The Lint Setting That Ate 12 GB


# 17 Duplicate Saves Weren't a Loop

## What I Was Working On

A heavy query kept showing up in our database's slow query log (a list of queries that ran too long). For one user, it ran 17 times for the same quarterly review form. My task was to find what called it and stop the repeats.

## The Problem

Seventeen copies of one query looks like a loop: code that runs the query once per item.

But when I checked the code path, one request ran this query exactly once. If there was a loop, it wasn't in the server code.

## How I Found It

Two logs told the story:

- **The slow query log.** All 17 queries came from one app server, but over 12 different database connections, and their times overlapped. That's not one request looping. That's many requests.
- **The request log.** The same user loaded the page once, then sent 17 POSTs to the form's save endpoint in 14.4 seconds. Each took 1.06–1.55 seconds.

The form was a plain HTML form behind a **Save** button, with no guard against double submits. Each save was slow because the query scanned a whole table (a missing index, tracked as a separate fix). While the page waited, every extra click sent the form again.

It wasn't just one person: a handful of other users had repeated saves too. Luckily, saving only sets a "done" flag to true, so the repeats cost database load, not bad data.

## The Fix

Disable Save as soon as the form submits (simplified):

```js
const form = document.getElementById("save-form");
const save = form.querySelector("button[type=submit]");
form.addEventListener("submit", () => { save.disabled = true; });
window.addEventListener("pageshow", (e) => {
  if (e.persisted) save.disabled = false;
});
```

The second listener matters. After a save, the server redirects to another page. If the user presses Back, the browser may restore the old page from its **bfcache** (back/forward cache, a frozen copy kept in memory). That copy still has Save disabled. `pageshow` with `persisted` set means the page came from that cache, so Save turns back on.

## Results

A throwaway browser test stubbed the save endpoint to answer after 1.5 seconds, then clicked Save 5 times, 300 ms apart:

| | POSTs sent |
|---|---|
| Before | 5 |
| After | 1 |

## The Rails Contrast

In Rails, Turbo Drive does this for you. Its docs say it sets the submit button's `disabled` attribute when a submission begins and removes it when the submission ends. Add `data-turbo-submits-with="Saving…"` and the button text changes while it waits, too.

This page was a server-rendered .NET view with a plain form, so nothing did that for us. The page needed its own small script.

## What I Learned

- **Repeated queries aren't always a loop.** Check their timing and connections. Overlapping queries on many connections meant many requests.
- **Line up the slow query log with the request log.** The database says what ran. The request log says who asked, and how often.
- **A slow button with no feedback gets clicked again.** Disable it while the request is in flight.
- **If you disable a button, plan for Back.** The bfcache can bring the page back with the button still off.

## TL;DR

One user's form was saved 17 times in 14.4 seconds, and it looked like a loop. The slow query log showed the queries overlapping across 12 connections, and the request log showed 17 separate POSTs. Each save took over a second while Save stayed clickable. The fix disables Save on submit and turns it back on when Back restores the page from the bfcache.

---

*The loop wasn't in the code. It was the Save button, clicked again and again.*


17 Duplicate Saves Weren't a Loop


# The Preflight Check That Asks One Question

## What I Was Working On

In "The Migration That Waited 15 Minutes," I capped how long a migration waits for a table lock at 10 seconds. That stops our own migration from waiting forever. It doesn't help when someone else's schema change is already stuck, like a person running an `ALTER TABLE` by hand during a deploy. My job was a check that runs before any migration and refuses to start in that case.

## The Problem

Every statement that touches a table takes a **metadata lock** on it (a lock on the table itself, not its rows). Normal reads and writes take shared ones. They don't block each other, and they're released when the statement ends. A schema change needs an exclusive one, and while it waits, MySQL gives it priority, so later queries on that table line up behind it.

If our migration joins that line, it only makes the line longer.

## What a Queue Looks Like

MySQL's `performance_schema.metadata_locks` table lists locks that are held and locks still wanted. `GRANTED` means a session holds the lock. `PENDING` means it asked and is still waiting.

That made the rule simple. In production, `PENDING` is a fact, not a threshold to tune. Shared locks don't wait on each other, so a pending one means someone is changing a schema right now and a queue already exists.

Staging is different. NHibernate's auto schema update runs schema changes when the app starts there, so `PENDING` is routine noise. The check runs in production only.

## The Fix

A small .NET console app runs before the EF Core migration bundles and reads the lock table for a short list of busy tables:

```sql
SELECT ml.OBJECT_NAME, ml.LOCK_TYPE, ml.LOCK_STATUS, th.PROCESSLIST_ID
FROM performance_schema.metadata_locks ml
JOIN performance_schema.threads th ON th.THREAD_ID = ml.OWNER_THREAD_ID
WHERE ml.OBJECT_TYPE = 'TABLE'
  AND ml.OBJECT_SCHEMA = @schema
  AND ml.OBJECT_NAME IN (@t0, @t1, @t2);
```

Any `PENDING` row that isn't the check's own connection means stop. It exits `0` (go), `2` (a lock is queued) or `3` (can't tell), and leaves `1` for crashes. The deploy script stops before the first migration on any non-zero exit.

Exit `3` matters most. Four setups would make an empty result look like a quiet server: `performance_schema` off, the metadata-lock instrument off, a connection string with no database (so the schema filter compares to NULL and matches nothing), or an empty table list. Each one now refuses instead of passing. I checked it against a local MySQL 8.0, including turning the instrument off to see the `3`.

## What I Cut

The first design was bigger. Each cut came from one question: is there evidence we need this?

- **No modes.** No report-only or off setting. It runs on production deploys, and nowhere else.
- **No 30-second transaction check.** The 10-second lock wait already caps what a long transaction can cost a deploy.
- **No bypass switch.** A `2` clears on its own, so you wait and re-run. Skipping it takes a branch that turns it off: slower on purpose, and it leaves a commit.

It has limits too. It wouldn't have stopped the original incident by itself: when that migration started, nothing was queued yet, and the line formed behind our own `ALTER`. And its first real run is a production deploy, because nothing else runs it.

## What I Learned

- **Gate on a fact, not a threshold.** "A lock is queued" is true or false. "A transaction is 30 seconds old" is a guess about what it does next.
- **An empty result needs proof the sensor was on.** Make "can't tell" its own answer.
- **Ask "is there evidence?" before each guard.** Several in the first draft didn't survive it.

## TL;DR

Before a production migration changes any schema, a small check reads MySQL's `metadata_locks` table. If a lock on a busy table is already `PENDING`, a queue exists, and the deploy refuses (exit `2`) instead of making it longer. If the check can't trust what it sees, it refuses too (exit `3`). No modes, no bypass.

---

*The cheapest time to say no to a migration is before it has touched anything.*


Sam Lee.

I create things for the web.

Latest Posts

The Lint Setting That Ate 12 GB

17 Duplicate Saves Weren't a Loop

The Preflight Check That Asks One Question