DEV Community: Isabelle Hue

Your fr.json is three keys behind en.json and nobody noticed until a French user did

Isabelle Hue — Tue, 02 Jun 2026 10:55:08 +0000

Every i18n setup I've shipped has the same slow rot: you add a feature, you add the English string, and you fully intend to backfill the other languages "later." Later never comes, the non-English files drift behind, and your French users see raw key strings or fall back to English. So I built a thing that just fills the missing keys in on the PR that introduced them.

The problem

You add a confirmation dialog. You touch en.json because that's the language you're thinking in:

// locales/en.json
{
  "cart": {
    "checkout": "Checkout",
    "confirm_title": "Confirm your order",
    "confirm_body": "We'll charge {{count}} item(s) to {cardLast4}. Continue?"
  }
}

// locales/fr.json  — still the old version
{
  "cart": {
    "checkout": "Commander"
    // confirm_title and confirm_body don't exist here
  }
}

Two new keys, zero new French. Depending on your i18n library, the French user now sees the literal cart.confirm_title, or an empty string, or a silent English fallback. None of those are what you wanted, and your test suite is perfectly happy because the keys all "exist somewhere."

The annoying part is it's invisible. The PR looks complete. CI is green. The gap only surfaces in production, in a language you don't read, reported by a user weeks later — if at all.

And the manual fix is its own trap: hand-translating {{count}} and {cardLast4} is exactly where placeholders get mangled, pluralized, or dropped.

How it works

i18n Autopilot is a GitHub Action that runs on every pull request:

It diffs your locale files and finds keys present in your base/source locale but missing in the others.
It translates only those missing keys with AI — it doesn't touch existing translations.
It preserves placeholders like {name} and {{count}} exactly, so interpolation and pluralization don't break.
It commits the filled-in translations back to the same PR, so the branch that added the English string ships with every other language already done.

After it runs on the PR above, fr.json comes back complete:

// locales/fr.json — after i18n Autopilot
{
  "cart": {
    "checkout": "Commander",
    "confirm_title": "Confirmez votre commande",
    "confirm_body": "Nous débiterons {{count}} article(s) sur {cardLast4}. Continuer ?"
  }
}

Note that {{count}} and {cardLast4} survived untouched — that's the part hand-translation and naive find-and-replace get wrong.

Try it

It's a free GitHub Action on the Marketplace: https://github.com/marketplace/actions/i18n-autopilot — add it to a workflow and your next PR comes back with the missing locale keys filled in. There's also a hosted Pro app if you don't want to manage the Action and API key yourself: https://i18n.useautopilot.dev

If you maintain anything multilingual, I'd love to hear how far behind your non-English files have quietly drifted. That number is always bigger than people expect.

Your AI code reviewer treats .svelte files like plain JS. That's how secrets leak to the browser.

Isabelle Hue — Tue, 02 Jun 2026 10:44:05 +0000

I build SvelteKit apps, and I lean on AI PR review like everyone else. But I kept noticing the generic reviewers green-lighting things that would absolutely break in production — because they parse a .svelte file as if it were a .js file and miss the framework rules entirely. So I built a reviewer that actually knows Svelte 5. Here's the footgun that pushed me over the edge.

The problem

SvelteKit has a hard rule: anything from $env/static/private (or $env/dynamic/private) must never reach client code. The compiler enforces it in a lot of cases, but not all — and the moment a private value flows through a regular module or a shared util, it can end up bundled into the browser.

Here's a snippet that looks completely innocent in a PR diff:

<!-- src/routes/contact/+page.svelte -->
<script>
  import { SENDGRID_API_KEY } from '$env/static/private';

  async function submit(e) {
    e.preventDefault();
    // "just calling the API directly from the component, ship it"
    await fetch('https://api.sendgrid.com/v3/mail/send', {
      method: 'POST',
      headers: { Authorization: `Bearer ${SENDGRID_API_KEY}` },
      body: new FormData(e.target)
    });
  }
</script>

<form on:submit={submit}>
  <input name="email" type="email" />
  <button>Send</button>
</form>

A generic AI reviewer reads this and sees: an import, a fetch, a form handler. Looks fine. It might even compliment your error handling.

What it misses: this is a .svelte component — it runs in the browser. SENDGRID_API_KEY gets shipped to every visitor's devtools. That's not a style nit, that's your provider key in plaintext on the public internet.

Same category of misses I kept seeing:

<script>
  // crashes SSR — window doesn't exist on the server
  const theme = localStorage.getItem('theme');
</script>

<!-- XSS: user-controlled string rendered as raw HTML -->
{@html comment.body}

<script>
  // reactivity silently lost — destructuring breaks the $state proxy
  let { count } = $state({ count: 0 });
  // mutating `count` now updates nothing
</script>

None of these are exotic. They're the everyday mistakes you make at 1am, and they all pass a JS-shaped review.

How it works

Svelte Autopilot is a GitHub Action that runs on every pull request. It's specialized for Svelte 5 / SvelteKit, so it reviews .svelte files with the framework's actual rules in mind, not generic JS lint:

Private env in client code — flags $env/static/private / $env/dynamic/private reaching anything that ships to the browser.
SSR-unsafe top-level access — window, document, localStorage at module/component top level.
{@html} on user input — XSS surface.
Rune reactivity bugs — destructured $state losing reactivity, $effect used where $derived is correct, and similar Svelte 5 rune mistakes.

It posts findings as a normal PR review with the line and the why. I tested it deliberately: gpt-4o catches all four categories above; generic reviewers and gpt-4o-mini miss them. That gap is the whole reason the product exists.

Try it

Free GitHub Action on the Marketplace — drop it in your workflow and it reviews your next PR. There's also a hosted Pro app if you'd rather not manage the workflow and keys yourself: https://svelte.useautopilot.dev

Repo + source: https://github.com/isabellehuecloser-ctrl/svelte-autopilot

If you ship SvelteKit, I'd genuinely like to know whether it catches something real in your repo. Build-in-public, so feedback is the point.

The 15 Postgres migration footguns that lock production — and how to catch them in PR review

Isabelle Hue — Tue, 02 Jun 2026 08:34:29 +0000

TL;DR — Most prod migration incidents come from a small, well-known catalogue of SQL patterns. Your CI doesn't catch them. Your staging database doesn't either, because it has 30 000 rows and production has 1.2 billion. This post catalogues the 15 footguns, with safe rewrites, and ships a free GitHub Action (Marketplace) that blocks them in the PR review.

A migration that ran in 0.4s locked production for 20 minutes

The exact pattern, from a real postmortem:

ALTER TABLE posts ALTER COLUMN category SET NOT NULL;

Tested on staging (30 000 rows) — green in 0.4 seconds. Shipped to production (a posts table with over 1 billion rows). Postgres took an ACCESS EXCLUSIVE lock, scanned every row to validate the constraint, and held the lock for 20 minutes.

For 20 minutes, no read, no write, nothing. Reader traffic queues, writers time out, the app degrades into a 503 page.

The mechanism is well documented. The fix takes three lines of safer SQL. And yet teams keep doing it, because nothing in the standard PR review flow surfaces "this statement will lock writers for the duration of a full-table scan".

This is one of fifteen footguns I want to put on the table.

Why staging never catches it

Staging databases lie to you in three different ways:

Volume. A SET NOT NULL that scans 30 000 rows runs in milliseconds. The same statement against 1.2 billion rows can run for the duration of an episode of a sitcom. Lock duration is roughly linear in row count.
Contention. Your staging instance has one developer poking at it; production has thousands of concurrent connections waiting on every row they need. The lock that's free on staging is a queue depth bomb on prod.
Versions and extensions. Lock-upgrade behavior changed between Postgres 11, 12, and 13. Subtle index-build semantics depend on patch versions. Staging often lags. Production often leads.

The team that wrote the postmortem above had a staging environment. The migration was reviewed. CI passed. None of that helped.

The catalogue — 15 patterns to never merge

Data loss

These permanently delete data, or break the running app version mid-deploy.

1. DROP COLUMN

ALTER TABLE users DROP COLUMN email; -- ❌

Permanent. And during the deploy window, the previous app version still reads email and crashes.

Safe rewrite: ship a code-side stop-reading-this-column release first. Optionally rename to email_deprecated for a release. Drop the column in a later migration once nothing references it.

2. DROP TABLE

DROP TABLE legacy_orders; -- ❌

Same as above, table-scale. Add a check: is anything still referencing it? Foreign keys? A delete in production at 3am can take a service down at 9am.

Safe rewrite: rename, observe for a release, drop later.

3. TRUNCATE

TRUNCATE sessions; -- ❌ unless you really mean it

Often used as a quick reset in dev that survives into a migration. Production teams rarely intend it.

Production locks

These take an ACCESS EXCLUSIVE lock and scan every row. On a big table, that's minutes of blocked writes.

4. SET NOT NULL on an existing column

ALTER TABLE users ALTER COLUMN phone SET NOT NULL; -- ❌

Postgres validates the constraint by scanning every row, holding ACCESS EXCLUSIVE for the duration. Even checking an existing NOT NULL constraint requires a scan.

Safe rewrite (Postgres 12+): add a CHECK (phone IS NOT NULL) NOT VALID constraint, VALIDATE CONSTRAINT in a separate transaction, then SET NOT NULL (which becomes O(1) because the check is already validated).

5. ADD COLUMN ... NOT NULL without a default

ALTER TABLE users ADD COLUMN age integer NOT NULL; -- ❌

Outright fails on any non-empty table — Postgres can't synthesize a value.

Safe rewrite: add nullable, backfill in batches, then add the constraint via the NOT VALID dance above.

6. ALTER COLUMN ... TYPE

ALTER TABLE users ALTER COLUMN id TYPE bigint; -- ❌

Rewrites the entire table. Locks for the duration. The "free" int → bigint upgrade has bitten more teams than any other type change.

Safe rewrite: add a new nullable column of the target type, backfill, swap the application read path, drop the old column much later.

7. CREATE INDEX without CONCURRENTLY

CREATE INDEX idx_users_email ON users (email); -- ❌ on Postgres

Holds SHARE lock — blocks writes until the index is built. On a big table, that's minutes.

Safe rewrite:

CREATE INDEX CONCURRENTLY idx_users_email ON users (email); -- ✅

8. CREATE INDEX CONCURRENTLY inside a Prisma/Drizzle migration

-- Looks safe! But this fails at runtime.
CREATE INDEX CONCURRENTLY idx_users_email ON users (email);

Both Prisma and Drizzle wrap migrations in a transaction by default. CONCURRENTLY cannot run inside a transaction. The migration errors out, your deploy fails halfway through, and now you have a half-applied schema to clean up by hand at 3am.

Safe rewrite: split the index into a separate migration with BEGIN/COMMIT stripped, or use the ORM's escape hatch (Prisma: a raw SQL migration created with --create-only and the transaction wrapper removed).

Silent breaks

These don't lock — they break consumers in subtle ways the deployed app version can't anticipate.

9. ADD CONSTRAINT ... FOREIGN KEY (without NOT VALID)

ALTER TABLE posts
ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users (id); -- ❌

Validates every existing row under a lock.

Safe rewrite: ADD CONSTRAINT ... NOT VALID, then VALIDATE CONSTRAINT in a separate, lock-free transaction.

10. ADD CONSTRAINT ... CHECK (without NOT VALID)
Same shape as the foreign-key case. Same fix.

11. ADD CONSTRAINT ... UNIQUE

ALTER TABLE users ADD CONSTRAINT uq_email UNIQUE (email); -- ❌

Builds the underlying unique index under a lock.

Safe rewrite: CREATE UNIQUE INDEX CONCURRENTLY, then ADD CONSTRAINT ... UNIQUE USING INDEX.

12. RENAME COLUMN

ALTER TABLE users RENAME COLUMN fname TO first_name; -- ❌ during deploy

Atomic on the DB side — but the previous app version still selects fname and crashes the second the rename commits.

Safe rewrite: add a new column, dual-write, migrate readers, drop the old column much later. Or, if downtime is acceptable, schedule it.

13. RENAME TABLE
Same pattern as rename column, one level up.

Lower severity but worth a heads-up

14. DROP INDEX without CONCURRENTLY

DROP INDEX idx_old; -- ⚠

Brief ACCESS EXCLUSIVE. Usually fast, but on a busy table can cause noticeable timeouts. Prefer DROP INDEX CONCURRENTLY (Postgres 9.2+).

15. Volatile defaults on ADD COLUMN

ALTER TABLE users ADD COLUMN token uuid DEFAULT gen_random_uuid(); -- ⚠

Postgres 11+ can skip the table rewrite for constant defaults — but gen_random_uuid() and now() are volatile and will trigger a full rewrite.

Safe rewrite: add the column nullable, backfill with the generator in batches, set the default afterwards.

What about `strong_migrations` / Squawk / Atlas?

These are excellent tools. None of them quite fits the modern stack:

ankane/strong_migrations — Rails-only. If you ship Rails, install this gem today.
Squawk — Postgres + raw SQL. Excellent linter, no understanding of Prisma/Drizzle migration semantics. You wire up the CI yourself.
Atlas — atlas migrate lint is a top-tier tool. They paywalled it in October 2025 ($9/dev + $59/CI project + $39/database).
Generic AI review bots (CodeRabbit, Greptile, Qodo) — don't model lock semantics. They'll happily approve a SET NOT NULL.

There's a gap: hosted, zero-config, deterministic, multi-ORM. So I built it.

Catch them in the PR — `migration-autopilot`

Migration Autopilot is a free, MIT-licensed GitHub Action that runs the 15 rules above on every pull request and blocks the merge if it finds a high-severity issue.

📺 60-second demo → — three real PRs, three rules triggered, three blocked merges.

Two minutes to set up:

# .github/workflows/migration-review.yml
name: Migration Autopilot
on: pull_request
permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: isabellehuecloser-ctrl/migration-autopilot@v0
        with:
          fail-on: high # block merge on dangerous migrations
          dialect: postgres

That's it. The detection is a deterministic rule engine — no OpenAI key required, no LLM hallucinations, no false positives. A merge-gating tool that cries wolf gets disabled within a week. The rules are derived from Squawk, strong_migrations, the Atlas PG301-311 series, and the postmortems linked above.

Supported migration sources (auto-detected): Prisma prisma/migrations/, Drizzle drizzle/, Rails db/migrate/*.rb (the Ruby DSL is parsed directly — no Ruby runtime needed), and raw SQL in any directory that smells like migrations.

Dialects: Postgres and MySQL. Postgres-specific rules (like CREATE INDEX CONCURRENTLY) don't fire on MySQL files.

What I'd love your feedback on

I'm a solo dev. The free Action is feature-complete; a hosted Pro version (1-click install, dashboard, multi-repo policy) is in early access.

What rule is missing? If you've hit a footgun the catalogue doesn't cover, open an issue.
What's the false-positive rate on your real codebase? Install the Action on a recent branch and tell me what fires wrongly. Zero false positives is the hardest commitment to keep.
Is the safe-rewrite text useful, or noise? I'd rather it be slightly opinionated than vague.

Source code, issues, contributions welcome:
github.com/isabellehuecloser-ctrl/migration-autopilot

If the Action catches a real footgun on a PR of yours — drop a ⭐ on the repo. That's how I know it's landing somewhere.

References & further reading:

DEV Community: Isabelle Hue

Your fr.json is three keys behind en.json and nobody noticed until a French user did

The problem

How it works

Try it

Your AI code reviewer treats .svelte files like plain JS. That's how secrets leak to the browser.

The problem

How it works

Try it

The 15 Postgres migration footguns that lock production — and how to catch them in PR review

A migration that ran in 0.4s locked production for 20 minutes

Why staging never catches it

The catalogue — 15 patterns to never merge

Data loss

Production locks

Silent breaks

Lower severity but worth a heads-up

What about strong_migrations / Squawk / Atlas?

Catch them in the PR — migration-autopilot

What I'd love your feedback on

What about `strong_migrations` / Squawk / Atlas?

Catch them in the PR — `migration-autopilot`