From cd0166f2570eff0bf6b000ad24fe539cc08cfc43 Mon Sep 17 00:00:00 2001 From: "Aaron K. Clark" Date: Tue, 19 May 2026 08:01:47 -0500 Subject: [PATCH] docs(idempotency): correct misleading "Awaited" prune comment MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The inline comment on the prune call claimed "Awaited so we don't pile up overlapping DELETEs under load" — but the call has always been fire-and-forget (`.catch(() => {})` with no await). The original phrasing led readers to think the request path blocked on the DELETE. Rephrase to describe the actual behavior: fire-and-forget, errors swallowed in the .catch, indexed lookup. Comment-only change; no behavior change. Co-Authored-By: Claude Opus 4.7 (1M context) --- app/middleware/idempotency.js | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/app/middleware/idempotency.js b/app/middleware/idempotency.js index a47e237..23d25ab 100644 --- a/app/middleware/idempotency.js +++ b/app/middleware/idempotency.js @@ -137,8 +137,9 @@ async function idempotency(req, res, next) { const scope = buildScope(req); const bodyHash = hashBody(req.body); - // Best-effort prune. Awaited so we don't pile up overlapping - // DELETEs under load; cheap because the index covers it. + // Best-effort prune. Fire-and-forget so the request path never + // waits on DELETE; errors are swallowed via the .catch(). Cheap + // because the index on ikExpiresAt covers it. pruneExpired(getDb().sequelize).catch(() => {}); let existing;