Build1 distinct publisher3 min readUpdated
quayside shipped 1.0.0 with every mutant killed and 26 review findings triaged, then ran a payment twice on the dropped-connection retry it exists to prevent.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
quayside, a zero-dependency idempotency library for Node.js, shipped 1.0.0 last week behind a 100% mutation score across 1,254 mutants with none suppressed, a storage contract suite run against real servers, and an adversarial review whose 26 verified findings were fixed or triaged [1][2][3][4]. Its author then reports that a dropped connection made it run a payment twice, which is the single scenario the library exists to prevent [5].
The core design is legible enough to reason about. The atomic create-if-absent write is the lock: `execute(key, fn)` writes an `IN_PROGRESS` record before the function runs, so there is no window between checking and locking [6]. Success moves the record to `COMPLETED` and replays it for a result TTL; failure deletes the record so retries run fresh; a crashed process is covered by the lock TTL [7]. Every transition out of `IN_PROGRESS` is guarded by a fencing token validated inside the store itself, Lua on Redis and token-conditional UPDATEs on SQL, so a holder that lost its lease gets a `FencingError` rather than overwriting a newer result [8].
The defect was not in any of that. It was four lines in the Fastify adapter, written days before the tag to fix a different finding, and it survived until the final security pass [9][10]. Fastify is hooks rather than a wrapping function, so the adapter bridges the engine across two of them: `preHandler` takes the lock and stashes a deferred, `onSend` resolves it with the captured response [11]. The review found that `onSend` is not guaranteed to run: `reply.hijack()` skips it, and so does a handler that never answers, leaving the deferred unsettled and the key locked until the lock TTL expires [12]. In the shipped configuration example that is 30 seconds of 409s per retry with nothing actually executing [13][14]. The fix was to settle the capture on connection close, since Node's raw `ServerResponse` emits `close` for every request regardless of what the framework lifecycle does [15].
The post as published stops mid-patch, so take the chain as inference rather than the author's own words: a dropped connection is a closed connection, and the library's failure path deletes the record so retries run fresh [7][15]. A retry arriving with the same key after that then finds nothing, and charges again [5].
What the metrics measured is worth being precise about. The 1,254 mutants were mutants of code that existed when the suite ran [2]. The 50-way concurrency races, SIGKILL recovery and split-brain fencing tests belonged to the storage contract suite, not to an HTTP adapter's hook bridge [3]. The adversarial pass produced 38 candidates, of which 26 survived verification and the ten worst were fixed before the tag, leaving 16 verified findings unfixed at release [4][16]. None of those instruments has an opinion about a state machine spread across two framework hooks and a socket event, because that failure is an ordering of events, not a mutated line.
The transaction to note is the trade the remediation made: an availability bug, where a stuck key returns 409 and the caller waits out 30 seconds, became a correctness bug that moves money [13][5]. In payments those are not the same severity, and a fix applied days before a tag gets a fraction of the scrutiny the code it patches already received.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Before release quayside achieved a 100% mutation score across 1,254 mutants, with every mutant dead and none suppressed; when a mutant was equivalent the rule was to delete or restructure the code rather than annotate it away.
quayside is an idempotency library for Node.js with a single-sentence API, execute(key, fn), which runs a function exactly once per key: if it already ran you get the stored result, if it is running you do not run it again. It has pluggable storage (memory, Redis, Postgres, MySQL), HTTP adapters for Express, Fastify, Hono and NestJS, and zero runtime dependencies. It shipped at 1.0.0 last week.
All quayside storage adapters pass one shared contract suite against real servers via Testcontainers, including 50-way concurrency races, SIGKILL crash recovery, and split-brain fencing where a stale holder must be rejected by the store itself.
An adversarial review pass on quayside produced 38 candidate findings, of which 26 survived verification, and the ten worst were fixed before the 1.0.0 tag.
The author's account is titled: my idempotency library had one job, and a dropped connection made it run the payment twice; the bug broke the library on the one scenario idempotency libraries exist for, the dropped connection followed by a retry with the same Idempotency-Key.
In quayside the atomic create-if-absent write is the lock: execute(key, fn) writes an IN_PROGRESS record before the user function runs, so there is no separate locking step and no gap between checked and locked.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but wholly first-party
The cluster is one self-published maintainer post. Its internal evidence quality is high for a narrative: named hooks and APIs, quoted code, explicit counts, and a seven-step causal chain from client abort to second charge. But every number and every mechanism claim is first-party and unverified — no repository, registry, advisory, issue thread or independent reviewer appears in the cluster, and one key figure (the fate of 16 verified findings) is only reachable by arithmetic on the author's own totals.
Fresh 1.0.0, no usage signal
The only adoption datapoint is the author's statement that the library reached 1.0.0 the week before publication. There are no downloads, dependents, production deployments, third-party integrations or user reports in the cluster, so real-world uptake cannot be distinguished from zero beyond the release itself.
Slightly overstated, self-corrected
The headline assurance figures (100% mutation score over 1,254 mutants, 26 verified findings triaged) are unverifiable and, on the author's own account, coexisted with a HIGH-severity payment-doubling defect that a passing test actively certified — so the metrics overstate demonstrated correctness. What keeps the gap small is that the post itself is the deflation: it explicitly says the numbers 'say nothing' about newly written code and narrates the failure in full. Adoption is not overclaimed anywhere.
Maintainer promoting own library
The author is the library's creator writing on a developer-content platform, so there is a clear promotional interest: the post opens with a feature list for quayside and links its credibility to disclosed rigour. The candour cuts the other way — voluntarily publishing a HIGH double-charge finding against your own 1.0.0 is costly self-disclosure — but the incentive to frame the assurance pipeline favourably and to omit unresolved findings remains, and no independent voice in the cluster offsets it.
Internally coherent, single-sourced
Confidence is capped by the single self-interested source and the absence of any corroboration, versioning detail or advisory. It is lifted by the account's internal consistency and specificity — the failure chain follows directly from the described lock state machine and the quoted four-line backstop, and the mechanism claims are mutually consistent rather than asserted in isolation.
build
The optional EntityManager is the bug: moving the transaction boundary into AsyncLocalStorage1 distinct publisher
build
The 680 MB database that was really a 17 GB disk: self-hosted support platforms fail at month six1 distinct publisher
build
A Timed-Out Reset SMS Is Not A Failed One, And Your Retry Code Probably Disagrees1 distinct publisher
build
Three services you can delete: queue, cache and search in one Postgres1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 17, 2026