Concurrent clicks on the same link silently lose count updates

Click counts are this product's core piece of data -- it's the entire reason the async click-logging path exists at all (see this project's README, "Async click logging"). Right now, whenever a link gets multiple clicks close together in time -- which is exactly what a link doing well looks like: shared in a group chat, posted somewhere with real traffic -- some of those clicks silently fail to get counted. Nothing errors, nothing logs a warning, GET /:code/stats just quietly reports a number lower than the true click count, forever. Anyone using click counts to judge which campaign link performed better, or to bill/report on traffic, is working from numbers that undercount exactly the links that matter most -- the popular ones -- and there's no error anywhere to tell them the number is wrong. This is a concurrency/correctness bug at the very heart of the product's core metric, which is why it carries real priority despite never producing a visible error.

incrementClickCount in src/lib/clickLogger.js now reads the current clicks value, computes +1 in application code, and writes that back -- a classic read-then-write. When multiple redirects for the same short code happen close together, two (or more) of these can both read the same clicks value before either has written its increment back, both compute the same +1 result, and both write the same value -- so N concurrent clicks can produce fewer than N total increments.

// From a Node REPL or script with DATABASE_URL set: const { createLink } = require('./src/lib/linkService'); const { incrementClickCount } = require('./src/lib/clickLogger');

const link = await createLink({ longUrl: 'https://example.com/race' }); await Promise.all(Array.from({ length: 50 }, () => incrementClickCount(link.shortCode)));

const prisma = require('./src/lib/prisma'); const updated = await prisma.link.findUnique({ where: { shortCode: link.shortCode } }); console.log(updated.clicks); // Expected: 50 // Actual: some number less than 50 (varies by run -- that's the nature of a race)

This is the exact anti-pattern this project's own code comments warn about. The doc comment directly above incrementClickCount in src/lib/clickLogger.js explains, in detail, why a single atomic SQL UPDATE ... SET clicks = clicks + 1 is required instead of a read-then-write, using the precise words "read clicks, compute +1, write clicks" to describe the exact pattern that causes lost updates. The current implementation does precisely the thing the comment says not to do -- read the row with prisma.link.findUnique, compute link.clicks + 1 in JavaScript, then write it with prisma.link.update. Between the read and the write, the Node.js event loop can freely interleave other concurrent calls to this same function, so two calls can both read the same starting value before either writes back. This bug is NOT deterministic and won't show up if you only ever call the function once at a time -- it only manifests under real concurrency, which is exactly the scenario a popular link creates.

Compare the current body of incrementClickCount against the doc comment directly above it in the same file, and against what this project's README says about "Atomic increment, not read-then-write." The fix is to express the increment as a single database statement that Postgres itself serializes, rather than three separate steps (read, compute, write) in application code with an await between each.