DEV Community: Rohit Bhadani

useEffect Fired Twice and It Found a Real Bug

Rohit Bhadani — Sat, 05 Sep 2026 03:34:36 +0000

useEffect fired twice, on mount, every single time, in development only. The API call inside it — a POST that created a resource — ran twice, and for about a day we had duplicate records showing up in a table that should have had exactly one insert per page load.

The first reaction, and why it was wrong

The instinct is to assume a bug — a rerender loop, a missing dependency, something actually broken. React 18's Strict Mode, in development, deliberately mounts, unmounts, and remounts every component once, specifically to surface effects that aren't properly cleaned up. It's not a bug in your code causing a double-fire; it's a bug in your code being caught by a feature built to catch exactly this.

useEffect(() => {
  console.log('mount'); // logs twice in dev, once in production
  const subscription = subscribeToUpdates();
  // no cleanup — this is the actual problem Strict Mode is surfacing
}, []);

Production builds don't do this double-invocation — it's development-only, and specifically Strict-Mode-only, which is why the duplicate inserts we saw locally would eventually have shown up in production too, just less predictably, under a race condition instead of a guaranteed double-fire.

Why this is a feature and not noise to suppress

An effect that safely tolerates being mounted, torn down, and mounted again is an effect that correctly declares its dependencies and cleans up after itself — which is exactly the property you need for effects to behave correctly under React's concurrent features generally, not just under Strict Mode specifically. The double-invocation in development is a cheap, automatic test for that property, running on every single page load without you writing a test for it.

The actual fix

useEffect(() => {
  const subscription = subscribeToUpdates();
  return () => subscription.unsubscribe(); // cleanup makes remounting safe
}, []);

For our specific case — a POST that shouldn't fire twice regardless of mount behavior — the deeper fix was recognizing that a side effect with real-world consequences (creating a database row) needs to be idempotent or explicitly guarded, because "this only runs once" was never a guarantee useEffect actually made, even before Strict Mode started enforcing the point loudly:

useEffect(() => {
  let cancelled = false;
  (async () => {
    const result = await createResource();
    if (!cancelled) setResource(result);
  })();
  return () => { cancelled = true; };
}, []);

The cancelled flag doesn't stop the double mount from happening — it stops the second mount's effect from acting on a component that's already been torn down, which is the actual property that matters.

Why we caught this before it reached more customers

The double-insert bug was already live before Strict Mode's double-fire made us go looking for it, which is the more important point: local development would have looked completely fine without Strict Mode enabled, and the race condition in production might have taken far longer to notice, showing up as an occasional support ticket about duplicate items rather than an obvious, reproducible pattern. We keep Strict Mode on for every environment we can, including staging deployments on disposable Krova Cubes that mirror production traffic patterns, specifically because catching this class of bug before a customer does is worth the minor noise of double-logged console output. I run Krova, so take the staging setup as informed rather than neutral, but enabling Strict Mode everywhere you reasonably can is free advice regardless of host.

What I'd check first

If an effect behaves differently than expected only in development, check whether you're running React 18+ with Strict Mode before assuming a logic bug. Then check whether the effect has a cleanup function and whether it would still behave correctly if mounted, unmounted, and mounted again in rapid succession — because that's the actual property Strict Mode is testing, and it's a property your effect needs regardless of whether Strict Mode is the thing that exposed its absence.

The CORS Header Was Right There and the Browser Blocked It Anyway

Rohit Bhadani — Fri, 04 Sep 2026 15:44:26 +0000

The browser console showed exactly what CORS errors always show — a request blocked for violating the same-origin policy — except the response headers, visible in the network tab, clearly included Access-Control-Allow-Origin: *. The header the browser wanted was right there. The browser rejected the request anyway.

The detail that's easy to miss in the network tab

Chrome's network inspector, by default, coalesces duplicate header names into a single display line — so Access-Control-Allow-Origin: * shown once in the UI can actually mean the header was sent twice by the server, and the browser is showing you a merged, deduplicated view rather than the literal wire response.

curl -s -D - https://api.example.com/data -o /dev/null | grep -i access-control

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: https://app.example.com

Two separate headers, both valid individually, sent by two different layers that each thought they were the one responsible for CORS: our nginx reverse proxy had a blanket add_header Access-Control-Allow-Origin *; for general API access, and the application server behind it independently set a specific origin for authenticated routes. Neither config was wrong on its own. Together, they produced a response with the header appearing twice — and per the Fetch spec, a response with multiple Access-Control-Allow-Origin values is treated as invalid, so the browser blocks the request rather than guessing which one you meant.

Why this is worse than a missing header

A missing CORS header fails immediately, obviously, the same way every time. A duplicate header fails in a way that looks, from the response body alone, like the header is present and correct — because it is present, twice, which is precisely the state that trips the spec's validation. Every piece of evidence you'd normally check says "this should work," and it still doesn't.

The fix

Removed the blanket nginx header and let the application server be the single source of truth for CORS decisions, since it's the layer that actually knows which origins should be allowed for which routes:

# removed this — the app now owns CORS entirely
# add_header Access-Control-Allow-Origin *;

location /api/ {
  proxy_pass http://app_upstream;
  # no CORS headers added here
}

One layer, one header, no duplication possible by construction rather than by discipline.

Where this kind of overlap tends to hide

This class of bug — two layers of infrastructure each independently and correctly configured, producing an incorrect result only in combination — is exactly why we keep our ingress configuration minimal on Krova: the managed HTTPS ingress terminates TLS and forwards to your Cube without injecting application-level headers like CORS on your behalf, so there's exactly one place — your own app or reverse proxy — that owns those decisions, not two competing ones split across a platform layer and your own config without either side being aware of the other. I run Krova, so take the specific setup as informed rather than neutral, but the debugging lesson generalizes: when a header looks right in the browser but the request still fails, check for duplicates on the wire, not just presence.

What I'd check first

curl -sD - against the failing endpoint, piped through grep -i access-control, before trusting anything the browser's network tab shows you. If you see the same header name more than once, that's the entire bug — find both places setting it and remove all but one.

I Ran git reset --hard in the Wrong Window

Rohit Bhadani — Thu, 03 Sep 2026 03:38:02 +0000

git reset --hard HEAD~3 — run in the wrong repository window, at 6:40pm, immediately followed by the specific kind of silence that happens when you realize what you just did before your brain finishes processing it. Three commits of uncommitted-adjacent work, gone from the working tree in under a second.

The first, most important fact: it's very likely still there

git reset --hard moves the branch pointer and resets the working tree, but Git doesn't actually delete commit objects just because nothing points at them anymore — they sit in the object database, unreferenced, until garbage collection eventually cleans them up, which for most repos happens rarely enough that "eventually" can mean weeks.

git reflog

a1b2c3d HEAD@{0}: reset: moving to HEAD~3
e4f5g6h HEAD@{1}: commit: add retry logic to payment webhook
7h8i9j0 HEAD@{2}: commit: fix currency rounding
k1l2m3n HEAD@{3}: commit: initial webhook handler

The reflog is a local log of everywhere HEAD has pointed recently, and it survives a reset because a reset is just another entry in it, not an erasure of the ones before it.

git reset --hard e4f5g6h

Working tree restored to exactly the state before the reset, all three commits back, in the time it takes to read this sentence.

When the reflog isn't enough

If the commits were never made at all — you ran reset --hard on genuinely uncommitted changes — the reflog can't help, because it only tracks where HEAD and branches have pointed, not file contents that were never committed. That's a real loss, and the only real defense against it is committing early and often, including throwaway "wip" commits you intend to squash later, specifically because an uncommitted change has no recovery path at all.

If the commits were committed and the reflog entry has expired — Git's default is to keep unreachable reflog entries for 90 days, reachable ones for longer — git fsck --unreachable can sometimes still find dangling commit objects directly:

git fsck --unreachable --no-reflog | grep commit
git show <hash>  # inspect before deciding it's the one you want

Why I test destructive Git operations before running them for real, now

The reflog saved this specific mistake, and it also taught me not to rely on remembering it exists at 6:40pm under stress. The actual habit that stuck: for anything genuinely destructive and unfamiliar — an interactive rebase across a long history, a filter-branch, anything with --hard or --force in it — I run it first against a disposable clone of the repo, confirm it does what I think it does, then run it for real.

# rehearse the risky operation somewhere it can't hurt anything
krova cubes create git-rehearsal --cpu 1 --ram 2 --disk 10
# clone, attempt the operation, inspect the result, then destroy regardless of outcome

Running the rehearsal on a disposable Krova Cube costs a few minutes and effectively nothing, and destroying it afterward means there's no cleanup step to skip — the environment simply stops existing once I have my answer. I run Krova, so read the specific workflow as informed rather than neutral, but the underlying discipline — rehearse destructive Git operations somewhere disposable before running them on a repo you care about — is worth adopting regardless of what you rehearse it on.

What I'd check first

Before assuming lost work is actually lost, run git reflog and read it fully — the commit you want is very likely sitting in there under a hash you haven't looked at yet. And before your next genuinely destructive Git command, consider whether rehearsing it somewhere disposable costs you anything at all compared to finding out the hard way.

Postgres Said Too Many Clients While Sitting at 40% CPU

Rohit Bhadani — Wed, 02 Sep 2026 11:46:03 +0000

The error was FATAL: sorry, too many clients already, thrown by a Postgres instance that, by every dashboard we had, was using 40% of its CPU and half its RAM. Plenty of headroom. It rejected the connection anyway, which is the specific kind of outage that makes people distrust their own monitoring.

The number nobody had looked at

max_connections was set to 100, the Postgres default nobody changes unless something forces the question. We weren't near it on any given request — we were near it in aggregate, because every one of our six app instances kept its own connection pool of 20, and 6 × 20 is 120 before Postgres even finishes its own reserved slots for replication and superuser access.

SELECT count(*) FROM pg_stat_activity;
-- 97, climbing toward 100 during traffic spikes

Each connection, busy or idle, holds a backend process in Postgres with its own memory overhead — a few megabytes each, which is why "just raise max_connections to 1000" is the advice that fixes the symptom and quietly creates a memory problem three weeks later.

What actually fixed it

PgBouncer in transaction mode, sitting between the app and Postgres, multiplexing hundreds of app-side connections onto a much smaller pool of real backend connections:

[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20

App-side, nothing changed except the port it connected to. Real Postgres connections dropped from 97 peak to a steady 20, with headroom that didn't depend on how many app instances we happened to be running that week.

Why this stayed invisible so long

The connection ceiling scales with instance count × pool size, and both of those numbers grow independently, usually for unrelated reasons — you scale instances for traffic, you scale pool size because someone hit a slow-query timeout once and bumped it. Nobody multiplies the two together until Postgres does it for you, out loud, during a traffic spike.

This is also where the machine underneath quietly matters. We'd been running Postgres on a shared-tenancy VPS where "half your RAM" was a number we trusted less than we should have — on an oversold host, headroom on a dashboard isn't the same guarantee it looks like. Since moving that database onto a Krova Cube, RAM is reserved 1:1 — no overselling, no thin provisioning — so when pg_stat_activity and free -h say there's room, there actually is room, and pooling fixes are fixes rather than guesses against an unknown neighbor's usage. I run Krova, so take the specific plug as informed rather than neutral, but the pooling fix works regardless of host.

What I'd check first

SELECT count(*) FROM pg_stat_activity; against SHOW max_connections;, and separately, (number of app instances) × (pool size per instance). If the second number is anywhere near the first, you don't have a Postgres problem, you have an arithmetic problem that Postgres is enforcing on your behalf.