DEV Community: sravan27

I keep finding the same Stripe webhook bugs in SaaS launches

sravan27 — Thu, 11 Jun 2026 15:50:57 +0000

I keep finding the same Stripe webhook bugs in SaaS launches

Most early SaaS billing bugs are not in Stripe Checkout itself. They are in the glue around it:

trusting the success redirect instead of the signed webhook
parsing JSON before signature verification
missing idempotency for retry events
reflecting verifier errors from unauthenticated webhook routes
updating subscription state without a replay/audit trail
letting "Pro" access drift from the payment source of truth

Over the last few days I have been shipping small public fixes around exactly this class of problem.

Recent examples:

Morphix: Cloudflare Worker Stripe webhook with signature verification, Supabase subscription sync, and event idempotency ledger

https://github.com/yiyuanlee/morphix/pull/25
Open Mercato: hardened unauthenticated payment/shipping provider webhooks against raw verifier error reflection and missing rate limiting

https://github.com/open-mercato/open-mercato/pull/2680
Covenant: webhook signatures hardened against replay and secret rotation gaps

https://github.com/wienerlabs/covenant/pull/229
Volunteerflow: made a Stripe invoice.paid Founders Circle counter update transactional instead of partially committing user/counter state

https://github.com/ppppowers/volunteerflow-project/pull/49

The pattern is boring in the best possible way: payment systems should be boring.

The 48-hour version

For a small SaaS that is about to turn on paid plans, I can take a bounded payment assurance sprint:

inspect Checkout / webhook / subscription state flow
verify signed webhook handling and raw-body behavior
add idempotency around Stripe retry events
ensure subscription status and entitlement state have one source of truth
add a small regression test or smoke script
leave a deploy/runbook note so the next failure is diagnosable

Fixed scopes I am taking:

$2,000 / 48 hours: one payment path hardened and documented
$5,000 / 5 days: full launch pass across Checkout, webhook, subscription mirror, Pro gate, pricing page handoff, and smoke test

I am not dropping a checkout link into a blog post. If you have a live Stripe/Supabase/Cloudflare/Vercel billing path and want me to take the first sprint, reply with:

repo or relevant code paths
what payment state should unlock
current deploy target
whether test-mode Stripe keys/webhook secret are ready

I will send a fixed scope and payment link only if it is a fit.

GitHub: https://github.com/sravan27

9 silent-row-loss fixes in 7 days across 7 OSS databases

sravan27 — Sun, 07 Jun 2026 09:00:43 +0000

Update June 8: tracking page with full audit summary + sprint pricing at https://silentdrop-sravan.vercel.app.

A pattern: a JavaScript database re-implements four common SQL operators - upper/lower, length/substr, case-insensitive match, range comparison. The implementation looks right. The tests pass. The CI is green. And then the moment a user's data contains the German ß, a fi ligature, an emoji, a Turkish dotted-i, or a CJK Extension B character, the operator silently returns the wrong rows. No error. No log. Just less data than the user expected, or the wrong data.

I've now shipped this exact bug class to seven open-source JavaScript database query layers in seven days. Nine PRs. None of them throw. All of them silently return wrong rows. Here's the streak:

PowerSync (#644) - LIKE/range semantics. Merged. Funded a paid 48-hour follow-on sprint.
PowerSync (#645) - CAST semantics. Merged.
PowerSync (#646) - division by zero. Merged.
PowerSync (#647) - json_each over scalar. Merged.
PowerSync (#662) - JOIN parsing silently syncs zero rows. Open.
PowerSync (#663) - upper/lower ASCII vs Unicode case-fold divergence. Open.
PowerSync (#664) - length() UTF-16 code units vs SQLite code points. Open.
PowerSync (#665) - substring() splitting surrogate pairs. Open.
TanStack DB (#1574) - ASCII case fold in upper/lower/ilike. Open today.

Plus earlier same-class fixes in Rocicorp's Zero, InstantDB, ElectricSQL, Dexie, and RxDB.

The pattern is always the same shape

A JS database re-implements a SQL operator in JavaScript:

// PowerSync sync-rules - before
const upper = { call(value) { return value?.toUpperCase() ?? null } }

// TanStack DB - before
case `upper`: return (data) => {
  const value = arg(data)
  return typeof value === `string` ? value.toUpperCase() : value
}

String.prototype.toUpperCase() is locale-aware and length-changing:

input	`.toUpperCase()`	SQLite's `upper()`
`'straße'`	`'STRASSE'` (6 -> 7)	`'STRAßE'`
`'ﬁle'`	`'FILE'` (3 -> 4)	`'ﬁLE'`
`'İ'.toLowerCase()`	`'i̇'` (1 -> 2, combining dot above)	`'i'`
`'I'.toLowerCase()` (tr-TR)	`'ı'`	`'i'`

When the JS re-implementation and the source database disagree, the bucket key the client looks up and the bucket key the server wrote silently mismatch. The row doesn't appear on the client. No error fires.

Same pattern for length() - JavaScript's String.prototype.length counts UTF-16 code units, SQLite's length() counts code points. They disagree by 2x on every emoji, CJK Extension B-G character, and ancient script glyph. Same for substring() - JS slices on code units and can return unpaired surrogates. Same for case-insensitive LIKE / ilike - same toLowerCase() length-change problem.

The fix is always the same shape too

Stop calling locale-aware JS string methods on data the database is supposed to be authoritative about. Use ASCII-only case fold loops, iterate by code points (for...of or [...text]), and walk surrogate pairs deliberately.

It's about 30 lines of JS to catch the four common cases. I packaged it:

npm i silentdrop

silentdrop is a zero-dependency MIT correctness checker. You wire your query layer's operators (like, ilike, gt, etc.) and it runs the four divergence classes against them, naming each silent-row-loss it finds.

Same lens applied to LLM outputs (missing required fields, enum drift, hallucinated IDs that look syntactically valid, claim-vs-list mismatches):

npm i silentdrop-llm

What makes this worth the hour to run

Every single time I have run silentdrop or its sibling discipline on a new database, I have found a real bug. PowerSync (8), TanStack DB (1 just today), Zero, InstantDB, Electric, Dexie, RxDB. The bug class has 100% hit rate on JS query layers that claim SQL parity. The fix is small. The user impact is real - some user's row, somewhere, has a ß in it, and the row is currently silently missing.

If your database/sync layer is correctness-critical and you'd rather have the whole operator surface hardened by hand - same pass as the nine PRs above - I take that on as a fixed 48-hour sprint, no-find-no-charge. $1,000 flat: https://buy.polar.sh/polar_cl_z0eLsPUJeMwrcNs4MQPAQbKIM3Rbdb8fLDgVj2RZcmr. Or smaller scope - one specific operator I find a divergence on, repro + fix + PR delivered - $500: https://buy.polar.sh/polar_cl_G0fuUHHZ1tg9E0oe7gluje9gs44l8FAqVnfwS2AJkbw.

Otherwise, npm i silentdrop is free and the first bug it finds will pay you back in the prevented hours of debugging.

How I shipped 8 silent-row-loss fixes to one OSS database in 24 hours - the same class repeating

sravan27 — Sat, 06 Jun 2026 16:08:39 +0000

Update June 8: tracking page with full audit summary + sprint pricing at https://silentdrop-sravan.vercel.app.

A JS database that re-implements SQL operators silently returns the wrong rows. Not occasionally. Not for one obscure case. Every day, in production, for any user data containing characters outside a-z and a 16-bit integer.

I went looking for one of these in PowerSync's sync rules engine last month. I found four, got them merged, and got paid for a 48-hour hardening sprint. This week I came back and found four more. All same class. None of them throw. All of them silently return the wrong rows.

Here are the four open today:

1. JOINs in Sync Streams silently sync zero rows

streams:
  user_chat:
    queries:
      - >
        SELECT cm.* FROM chat_messages cm
        INNER JOIN chat_conversations ON cm.conversation_id = chat_conversations.id
        WHERE chat_conversations.user_id = auth.user_id()

Looks fine. Aliases the source table inside an INNER JOIN. The result: zero rows sync to the client. No validation error. No runtime error. Just an empty client database and a user wondering why their chat history is gone.

Root cause: the parser's filter compilation doesn't track joined tables, so chat_conversations.user_id resolves to a value the SqlTools doesn't recognize, and the filter degenerates silently.

#662 surfaces this as a loud actionable error with the working subquery rewrite (#665 in the issue's test matrix). It doesn't fix JOIN support — that's a bigger change — but it stops the silent data loss.

2. `upper()` / `lower()` use Unicode case-folding while SQLite uses ASCII

const upper = {
  call(value) {
    return value?.toUpperCase() ?? null;
  },
};

String.prototype.toUpperCase() is locale-aware and length-changing. SQLite's default upper() is ASCII-only. They disagree the moment your data contains ß:

Input	JS `toUpperCase()`	SQLite `upper()`
`"hello"`	`"HELLO"`	`"HELLO"`
`"straße"`	`"STRASSE"`	`"STRAßE"`
`"ﬁle"`	`"FILE"`	`"ﬁLE"`

SELECT upper(name) AS bucket_key FROM users produces "STRASSE" server-side and "STRAßE" client-side. The client queries the "STRAßE" bucket and finds nothing. Row silently lost.

#663 replaces the JS calls with explicit ASCII-only fold loops.

3. `length()` counts UTF-16 code units instead of characters

String.prototype.length is a UTF-16 code-unit count. SQLite's length() is a character count (Unicode code points). For BMP characters they agree. For anything else — emoji, CJK Extension B-G, ancient scripts, U+10000 and up — they diverge by exactly 2x per character:

'😀'.length       // 2 (surrogate pair, two code units)
'a😀b'.length    // 4
'𐀀'.length       // 2
// SQLite: length('😀') = 1, length('a😀b') = 3, length('𐀀') = 1

A bucket-parameter query like SELECT * FROM messages WHERE length(content) > 100 will route messages with emoji to a different bucket than the client query asks for. Silent miss.

#664 walks the string with for..of (which iterates code points) and counts.

4. `substring()` slices on code units, not characters — splits surrogate pairs

Same root cause as length(). String.prototype.substring(0, 2) on "a😀bc" returns "a\uD83D" — an unpaired surrogate, which isn't a valid string. SQLite's substr('a😀bc', 1, 2) returns "a😀".

#665 spreads the string into a code-point array ([...text]) and slices that.

The pattern

Every one of these is the same shape:

The server-side evaluator re-implements a SQL operation in JavaScript.
The client SQLite implements the same operation differently.
The two agree for the data the maintainer tested with (ASCII strings, small integers, single-byte boundaries).
They disagree silently for everything else.
Bucket keys diverge, filters return the wrong rows, downstream code consumes corrupted state.

No error. No log line. Just wrong data.

I've shipped this exact bug class to PowerSync (8 times now), Rocicorp's Zero (2 merged), InstantDB (1 merged), ElectricSQL (PR open), and Dexie (PR open). I packaged the audit as an open-source checker so any team can run it against their own DB query layer:

→ silentdrop (npm i silentdrop)

Run it. The four checks took twenty minutes to write and have found a real bug in every JS database I've pointed them at.

If your sync/database layer is correctness-critical and you'd rather have the whole operator surface hardened by hand — same pass as the eight PowerSync PRs and the four other databases — I take that on as a fixed 48-hour sprint. Details and Polar checkout in the silentdrop repo.

Your JavaScript app is probably losing cents: money math done right

sravan27 — Fri, 05 Jun 2026 03:08:23 +0000

0.1 + 0.2 === 0.30000000000000004. You've seen it. In a toy it's a curiosity; in anything that touches money — billing, payroll, interest, payouts — it's a silent reconciliation bug waiting to happen. No error, no crash. The numbers just drift, and you find out when someone reconciles the books.

I spent this week on the money-critical core of a mortgage-servicing problem, and the discipline that keeps it correct comes down to three rules. They're simple, and most codebases break at least one.

Rule 1 — integer cents, never float dollars

let total = 0;
for (let i = 0; i < 10; i++) total += 0.1;
total === 1.0; // false — it's 0.9999999999999999

Floating-point can't represent most decimal fractions exactly, so every +, *, and / on dollar amounts can shave or add a fraction of a cent. One operation is invisible; ten thousand accruals is a real gap.

Represent money as integer cents (or whatever the minor unit is). $1,234.56 → 123456. Keep every intermediate value an integer and only format to dollars at the very edge:

const formatCents = (c) =>
  `$${Math.trunc(c / 100).toLocaleString("en-US")}.${String(Math.abs(c % 100)).padStart(2, "0")}`;

Rule 2 — make the day-count explicit, and compute it in UTC

Interest, late fees, and per-diem all depend on how many days. The day-count convention (Actual/365-Fixed, Actual/360, 30/360…) changes the answer, so it should be a stated decision in the code, never an accident of whatever Date math you reached for.

// Interest accrued at an annual rate over N days, Actual/365-Fixed, in integer cents.
function accruedInterestCents(principalCents, annualRatePct, days) {
  const p = BigInt(principalCents);
  const rateScaled = BigInt(Math.round(annualRatePct * 100)); // 8.99% -> 899
  // p * (rateScaled/10000) * days / 365  ==  p*rateScaled*days / 3_650_000
  return Number(roundDivHalfUp(p * rateScaled * BigInt(days), 3_650_000n)); // helper in the repo
}

And compute the day count in UTC — local-time date math drifts by a day across daylight-saving transitions:

const days = Math.round((Date.UTC(y2, m2 - 1, d2) - Date.UTC(y1, m1 - 1, d1)) / 86_400_000);

Rule 3 — round once per period, not per day

This is the subtle one. Compute the period's interest and round it once. If you round a per-day figure and then sum it, the rounding error compounds:

accruedInterestCents(1_000_000, 8.99, 30); // 7389  ($73.89) — round once over 30 days
perDiemCents(1_000_000, 8.99) * 30;         // 7380  ($73.80) — round daily, then sum

Same inputs. A 9-cent gap. On one loan it's noise; across a servicing book it's a reconciliation finding and an unhappy auditor. Decide exactly where rounding happens, and make it happen once.

The pattern

Integer cents, an explicit + UTC day-count, and round-once-per-period. None of it is hard — it's just easy to skip, and the failure mode is silent. So pin it down with tests:

$ node --test
✔ accrued interest is exact integer cents (Actual/365F, rounded once)
✔ rounds once per period, not per-day-then-summed (silent drift)
✔ payoff statement = principal + accrued interest + fees
✔ daysBetween counts leap day and is DST-proof (UTC)
✔ LTV in basis points, no float drift
...

Full runnable module + tests (per-diem accrual, payoff/discharge statements, LTV): https://github.com/sravan27/mortgage-money-math — node --test, zero dependencies.

This is the same "does the code silently return the wrong number?" discipline I've been applying to databases. I open-sourced a checker, silentdrop, that finds the query-layer version of these silent bugs in JS databases — the write-up is here. Money math is the same problem with a decimal point and higher stakes.

I take on correctness-critical builds — fintech money-math, database/sync query layers — as fixed-scope sprints; details are in the repos.

I found silent data-loss bugs in 5 production databases this month - here's the open-source checker

sravan27 — Thu, 04 Jun 2026 14:44:33 +0000

Update June 8: tracking page with full audit summary + sprint pricing at https://silentdrop-sravan.vercel.app.

Most database bugs throw errors. The dangerous ones don't — they quietly return the wrong rows. No exception, no log line, just a query that silently drops or over‑matches data. That's the worst kind of bug, because nothing tells you it happened.

This month I went hunting for exactly that failure mode in JavaScript databases — the client‑side, embedded, and sync databases that re‑implement SQL‑ish operators (LIKE, case‑insensitive match, range comparison) in JS. I found it, and got fixes merged or under review, in five production databases:

Database	Bug	Status
PowerSync	LIKE / range semantics	merged (#644)
Rocicorp's Zero	range / comparison	merged (#6083, #6088)
InstantDB	`$like` / `$ilike` newline	merged (#2714)
ElectricSQL	LIKE newline + escaped wildcards	PR #4437
Dexie	case‑fold drops rows	PR #2306

Then I packaged the audit into an open‑source tool so you can run it on your database: silentdrop — npm i silentdrop.

A concrete one: Dexie silently drops rows

Dexie is the dominant IndexedDB wrapper (~2M downloads/week). Its equalsIgnoreCase walks the index assuming case conversion is length‑preserving. It isn't — German ß → SS, ligatures ﬁ → FI, Turkish İ. So:

await db.items.where('name').equalsIgnoreCase('straße').toArray()
// expected: ['straße', 'STRAßE', 'Straße']
// actual:   ['straße', 'Straße']   ← 'STRAßE' silently dropped

No error. A row that matches by the database's own case‑insensitive contract simply isn't returned. (Reported as Dexie #2306.)

Why it happens

These engines compile LIKE to a RegExp, or compare strings with JS operators, and the gaps from real SQL semantics are invisible:

LIKE and newlines — in SQL, % matches any sequence including \n. A RegExp without the dotAll flag silently misses rows containing newlines.
LIKE metacharacters — LIKE 'a.b' must match the literal a.b, not axb. Translate to RegExp without escaping and you over‑match — a correctness and injection risk.
Case folds that change length — the Dexie one above.
Non‑BMP ordering — SQL/Postgres orders text by code point; naive JS comparison orders by UTF‑16 code unit, so an emoji (U+1F600) sorts below U+F000 and a range query silently drops it.

The checker

silentdrop runs these cases against your database's operators and reports the divergences. You wire a tiny adapter:

import { check, report } from "silentdrop";

const adapter = {
  async reset()         { /* clear the store */ },
  async seed(values)    { /* insert string values */ },
  async like(pattern)   { /* run a LIKE query, return matches */ },
  async ilike(needle)   { /* case-insensitive equality */ },
  async gt(bound)       { /* values > bound */ },
};

report(await check(adapter));

Run it against Dexie and it flags the case‑fold drop live; run it against AlaSQL and it passes the LIKE tests but flags the code‑point ordering divergence. A complete, runnable Dexie example is in the repo.

Why you should care

If you store names, addresses, search terms — anything with international characters — and you rely on case‑insensitive lookup or range queries for correctness (uniqueness checks, "is this taken?", access checks, "everything ≥ X"), you may be silently losing rows in production today. The fix is usually small. Finding it is the hard part — that's what the tool is for.

MIT‑licensed, zero runtime dependencies: https://github.com/sravan27/silentdrop. PRs adding adapters for more databases are very welcome.

If your sync/database layer is correctness‑critical and you'd rather have the whole operator surface hardened by hand — the same pass behind the five databases above — I take that on as a fixed 48‑hour sprint; details are in the repo README.

Your structured outputs are probably less portable than you think

sravan27 — Sun, 19 Apr 2026 16:22:26 +0000

Structured outputs are less portable across LLM providers than they look.

A schema change can seem harmless and still break one provider while passing another.

I built Schema Gateway for that exact failure mode.

What it does:

compile one schema into provider-ready request shapes
diff a baseline schema against a candidate schema
lint for portability issues
normalize payloads against a schema

It’s built for people working across providers like OpenAI, Gemini, Anthropic, and Ollama, where “structured output support” sounds similar until the edge cases show up.

There’s an open-source/local path, plus a hosted Starter Access if you want to try the hosted API quickly.

Main thing I’m looking for:
feedback from people actually shipping structured outputs or comparing providers in production. I’m especially interested in whether this pain is strong enough to justify a dedicated guardrail in real workflows.

Live here:
https://schema-gateway.sridharsravan.workers.dev/

DEV Community: sravan27

I keep finding the same Stripe webhook bugs in SaaS launches

I keep finding the same Stripe webhook bugs in SaaS launches

The 48-hour version

9 silent-row-loss fixes in 7 days across 7 OSS databases

The pattern is always the same shape

The fix is always the same shape too

What makes this worth the hour to run

How I shipped 8 silent-row-loss fixes to one OSS database in 24 hours - the same class repeating

1. JOINs in Sync Streams silently sync zero rows

2. upper() / lower() use Unicode case-folding while SQLite uses ASCII

3. length() counts UTF-16 code units instead of characters

4. substring() slices on code units, not characters — splits surrogate pairs

The pattern

Your JavaScript app is probably losing cents: money math done right

Rule 1 — integer cents, never float dollars

Rule 2 — make the day-count explicit, and compute it in UTC

Rule 3 — round once per period, not per day

The pattern

I found silent data-loss bugs in 5 production databases this month - here's the open-source checker

A concrete one: Dexie silently drops rows

Why it happens

The checker

Why you should care

Your structured outputs are probably less portable than you think

2. `upper()` / `lower()` use Unicode case-folding while SQLite uses ASCII

3. `length()` counts UTF-16 code units instead of characters

4. `substring()` slices on code units, not characters — splits surrogate pairs