DEV Community: Rowan Hale

A valid webhook can still be a duplicate

Rowan Hale — Thu, 08 Oct 2026 09:07:07 +0000

A receiver can see the same event twice even when both deliveries have valid signatures. The first request may have been accepted while its acknowledgement was lost. A retry then asks the receiver to accept the same event again.

Signature verification checks the HMAC over the timestamp and raw body against the configured key. Duplicate handling answers whether this receiver has already accepted that event. Keep both checks in the path before applying a business change.

This tutorial runs entirely offline. Its message and key are fictional. Its signing format follows TheFaithApp’s outgoing webhook contract, checked against the sender implementation. It does not start a server, contact an endpoint, process a payment, or handle personal information.

Verify the bytes before interpreting them

The relevant headers are:

Header	Purpose
`X-TheFaithApp-Timestamp`	Signing timestamp in Unix seconds.
`X-TheFaithApp-Signature`	`v1=` followed by a hexadecimal HMAC-SHA256 digest.
`X-TheFaithApp-Event-Id`	Event UUID retained across retries.
`X-TheFaithApp-Event`	Event type.

The signed input is the timestamp, a period, then the exact raw request body. Preserve those body bytes until verification finishes. Parsing JSON and serializing it again can change whitespace or encoding without changing its apparent meaning; the original signature will then fail.

The sample compares equally sized digest buffers using Node’s timingSafeEqual(). A strict signature-format check gives both buffers the expected length. Node notes that this function alone does not make all surrounding code timing-safe.

Run the complete fixture

Save this code as webhook-replay.mjs, then run node webhook-replay.mjs. It uses Node’s built-in modules and needs no package installation, account, credentials, environment variables, or network.

The clock is fixed for repeatable demonstrations. A five-minute window in either direction is an example receiver policy, including clock-skew tolerance; it is not a platform default. The public fixture key is test material. A real receiver uses its own endpoint secret. Rotation immediately invalidates the previous platform key; this single-key fixture does not model rotation, so receiver configuration needs the new key for subsequent attempts.

import { createHmac, createHash, timingSafeEqual } from 'node:crypto';
import { pathToFileURL } from 'node:url';

// Public fixture material, not a real endpoint secret or clock.
export const DEMO_KEY = 'public-fixture-key-never-use-in-production';
export const NOW = 1_700_000_000;
export const EVENT_ID = '11111111-1111-4111-8111-111111111111';
const UUID = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;

export function signBody(rawBody, timestamp, key) {
  return createHmac('sha256', key)
    .update(`${timestamp}.`, 'utf8').update(rawBody).digest();
}

export function makeDelivery({ id = EVENT_ID, timestamp = NOW, key = DEMO_KEY } = {}) {
  const payload = {
    id, type: 'platform.test', created_at: new Date(NOW * 1000).toISOString(),
    data: { message: 'Fictional replay drill' },
  };
  const rawBody = Buffer.from(JSON.stringify(payload), 'utf8');
  return {
    rawBody,
    // Node-style lower-case names; HTTP header names are case-insensitive.
    headers: {
      'x-thefaithapp-event': payload.type,
      'x-thefaithapp-event-id': payload.id,
      'x-thefaithapp-timestamp': String(timestamp),
      'x-thefaithapp-signature': `v1=${signBody(rawBody, timestamp, key).toString('hex')}`,
    },
  };
}

export function createReceiver({ key = DEMO_KEY, now = NOW, windowSeconds = 300 } = {}) {
  if (typeof key !== 'string' || !key) throw new TypeError('A nonempty fixture key is required.');
  if (!Number.isSafeInteger(now) || !Number.isSafeInteger(windowSeconds) || windowSeconds < 0) {
    throw new TypeError('The fixture clock and window must be integers.');
  }
  const processed = new Map(); // Single endpoint, one process, no durable storage.
  const acceptedIds = [];
  const reject = (reason) => ({ outcome: 'rejected', reason });

  function receive(delivery) {
    const { rawBody, headers } = delivery ?? {};
    if (!Buffer.isBuffer(rawBody) || !headers || typeof headers !== 'object') return reject('input');
    const timestamp = headers['x-thefaithapp-timestamp'];
    const signature = headers['x-thefaithapp-signature'];
    if (typeof timestamp !== 'string' || !/^[0-9]{1,16}$/.test(timestamp)) return reject('timestamp');
    const seconds = Number(timestamp);
    if (!Number.isSafeInteger(seconds) || Math.abs(now - seconds) > windowSeconds) return reject('window');
    const match = typeof signature === 'string' && /^v1=([0-9a-f]{64})$/.exec(signature);
    if (!match) return reject('signature-format');
    const supplied = Buffer.from(match[1], 'hex');
    const expected = signBody(rawBody, timestamp, key);
    if (!timingSafeEqual(supplied, expected)) return reject('signature');

    // Parse only after checking the signature over the original bytes.
    let payload;
    try { payload = JSON.parse(rawBody.toString('utf8')); }
    catch { return reject('json'); }
    if (!payload || typeof payload.id !== 'string' || !UUID.test(payload.id) ||
        payload.type !== 'platform.test' || !payload.data || typeof payload.data !== 'object' ||
        Array.isArray(payload.data)) {
      return reject('payload');
    }
    // The HMAC covers timestamp/body, not the event ID/type headers separately.
    if (headers['x-thefaithapp-event-id'] !== payload.id ||
        headers['x-thefaithapp-event'] !== payload.type) return reject('header-mismatch');

    const eventId = payload.id.toLowerCase();
    const digest = createHash('sha256').update(rawBody).digest('hex');
    if (processed.has(eventId)) {
      if (processed.get(eventId) !== digest) return reject('id-conflict');
      return { outcome: 'duplicate', eventId };
    }
    // This only records a fictional acceptance; it applies no business change.
    processed.set(eventId, digest);
    acceptedIds.push(eventId);
    return { outcome: 'accepted', eventId };
  }

  return Object.freeze({ receive, acceptedIds: () => [...acceptedIds] });
}

if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) {
  const receiver = createReceiver();
  const delivery = makeDelivery();
  const altered = { ...delivery, rawBody: Buffer.from(delivery.rawBody.toString().replace('drill', 'changed')) };
  console.table([
    { scenario: 'Valid fixture', ...receiver.receive(delivery) },
    { scenario: 'Same valid delivery again', ...receiver.receive(delivery) },
    { scenario: 'Altered body, original signature', ...receiver.receive(altered) },
    { scenario: 'Wrong key', ...createReceiver({ key: 'another-public-fixture-key' }).receive(delivery) },
    { scenario: 'New retry signature, same event ID', ...receiver.receive(makeDelivery({ timestamp: NOW + 10 })) },
  ]);
  console.log('Fictional acceptances:', receiver.acceptedIds().length);
  console.log('Offline fixture only: no HTTP server, network, durable inbox, or business side effects.');
}

The output includes one acceptance, duplicate deliveries, and failures for altered bytes and a wrong key. A retry gets a new signing timestamp while retaining the same authenticated event identity and body. It remains a duplicate even though its signing timestamp and HMAC signature change. The body bytes and stored body hash remain identical.

The receiver parses the verified body and uses its id for duplicate handling. It also checks the ID and type headers against that body. The signature covers the timestamp and body; those two header fields are not independently included. Changing an unsigned header must not route the event differently or bypass the stored identity.

This receiver accepts only the test event type. That allowlist, object-shaped data check, canonical UUID key, header consistency check, and rejection of a changed body under an existing ID are sample policies. The signature and freshness checks run before dedupe, so a stale delivery is rejected even if its event ID was previously accepted.

Make acceptance durable in a real receiver

The Map demonstrates duplicate handling for one endpoint in one synchronous process. A fresh receiver accepts the fixture again because its memory is empty. It does not protect multiple workers or survive a restart.

A production design needs a durable inbox, a unique key scoped to the configured endpoint and authenticated event ID, and atomic acceptance of the business change or durable work. The documented acknowledgement boundary is durable acceptance before returning a successful HTTP response. This fixture returns JavaScript outcomes and sends no HTTP acknowledgement.

Keep ordering separate

The checked contract supplies no per-resource revision or total-order guarantee. Neither an attempt’s signing timestamp nor an envelope’s created_at establishes a documented resource version. This fixture therefore does not choose a winner between distinct events that change the same resource. Define reconciliation only after verifying the upstream lifecycle and ordering contract.

The automated checks cover the fixed signing vector, altered and reformatted bodies, wrong keys, repeated valid deliveries, freshly signed retries, malformed inputs, window boundaries, header tampering, and the memory-reset limitation. They test this local fixture; no live sender, durable database, concurrent worker, payment, or ordering guarantee is validated.

Disclosure: AI generated the tutorial and code. Automated checks cover the offline fixture; no human technical review or live integration test is claimed.

Rowan Hale is TheFaithApp's editorial pen name.

A payment redirect is not a confirmed payment

Rowan Hale — Thu, 08 Oct 2026 08:47:57 +0000

A payment screen returns to your app with a success label. That is an event your interface can observe. The service responsible for verifying the payment may still be processing its result.

Keep those two facts separate. A return can prompt your app to check status; it should not independently replace the authoritative result. Closing the provider window and reaching a client wait limit are also observations, rather than proof of payment failure or cancellation.

This distinction matters when confirmation arrives later, a status update is delivered twice, or an old response arrives after a newer one. Stripe’s Checkout fulfillment guide explains why fulfillment cannot rely only on a landing-page visit and why server processing must handle repeated calls for the same checkout.

Choose clear display states

The example uses four application states. These are a teaching model, not a claim that every payment API returns these exact values.

State	What the interface can say
pending	Waiting for an authoritative result, or the server still reports processing.
succeeded	The authoritative source reports success.
failed	The authoritative source reports failure.
cancelled	The authoritative source reports cancellation.

Notice that a closed browser window does not assign cancelled. A local timeout does not assign failed. Keep enough context to explain what happened without turning uncertainty into a financial result.

For the mock, an authoritative update contains a checkout identifier, a positive integer revision, and one of those states. The imaginary backend owns the revision counter and publishes newer snapshots with larger values. These fields and the ordering contract are invented for this example. Adapt ordering to your actual backend; do not assume a provider event identifier or timestamp is an equivalent revision.

Run the local simulation

Save the complete sample as payment-states.html and open it in a modern browser. No build, account, credential, payment provider, network call, or personal information is needed.

Start by pressing Provider returns “success.” The payment stays pending. Press Confirm after 1.2 seconds to see a separate mock server update arrive later. Use the four server buttons to inspect each state.

The controls deliberately let you supply authoritative-looking values locally. They demonstrate rendering and ordering, not a secure payment protocol. A production client must receive its result through the backend or SDK responsible for verification; this sample provides no authentication, webhook verification, or payment processing.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Payment confirmation state demo</title>
  <style>
    * { box-sizing: border-box; }
    body { margin: 0; color: #20342e; background: #f4f6f2; font: 16px/1.6 system-ui, sans-serif; }
    main { max-width: 940px; margin: auto; padding: 40px 20px; }
    h1, h2 { line-height: 1.2; }
    h1 { font-size: clamp(28px, 5vw, 42px); margin: 8px 0 16px; }
    h2 { font-size: 20px; margin-top: 0; }
    p { max-width: 70ch; }
    .eyebrow, small { color: #526a60; }
    .panel { padding: 24px; background: white; border: 1px solid #ced9d0; border-radius: 12px; margin: 20px 0; }
    .grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(min(100%, 300px), 1fr)); gap: 20px; }
    .grid .panel { margin: 0; }
    #state { font-size: 28px; font-weight: 750; text-transform: capitalize; }
    #state[data-status="succeeded"] { color: #17623d; }
    #state[data-status="failed"] { color: #8a302b; }
    #state[data-status="cancelled"] { color: #635241; }
    button { font: inherit; color: #20342e; background: #eef3ef; border: 1px solid #9fb5a8; border-radius: 6px; padding: 10px 14px; margin: 5px 5px 5px 0; cursor: pointer; }
    button:focus-visible { outline: 3px solid #c08b27; outline-offset: 3px; }
    #delay { background: #235b43; color: white; }
    #log { padding-left: 24px; overflow-wrap: anywhere; }
    #log li { margin: 6px 0; }
    code { overflow-wrap: anywhere; }
  </style>
</head>
<body>
  <main>
    <div class="eyebrow">Fictional local demo · no payments or network calls</div>
    <h1>A return is not a confirmation</h1>
    <p>Provider events describe the payment screen. Mock server updates decide the payment state. The example uses a hypothetical versioned status contract, not a payment API.</p>

    <section class="panel" aria-label="Current payment state">
      <div id="status-region" role="status" aria-live="polite">
        <div id="state" data-status="pending">Pending</div>
        <p id="message">Waiting for server confirmation.</p>
        <small id="revision">No server update accepted yet.</small>
      </div>
      <p id="observation">No provider event observed.</p>
      <small>Fictional checkout: <code>demo-001</code>. Reloading or Reset restores the initial state.</small>
    </section>

    <div class="grid">
      <section class="panel" aria-labelledby="provider-title">
        <h2 id="provider-title">Provider and client events</h2>
        <p>These events do not prove that money arrived or that a checkout was cancelled.</p>
        <button id="provider-return" type="button">Provider returns “success”</button>
        <button id="provider-close" type="button">Close provider window</button>
        <button id="wait-limit" type="button">Client wait limit reached</button>
      </section>
      <section class="panel" aria-labelledby="server-title">
        <h2 id="server-title">Mock authoritative updates</h2>
        <p>Each button delivers a new revision for the same fictional checkout.</p>
        <button type="button" data-server="pending">Pending</button>
        <button type="button" data-server="succeeded">Succeeded</button>
        <button type="button" data-server="failed">Failed</button>
        <button type="button" data-server="cancelled">Cancelled</button>
        <button id="delay" type="button">Confirm after 1.2 seconds</button>
      </section>
    </div>

    <section class="panel" aria-labelledby="log-title">
      <h2 id="log-title">Event log</h2>
      <ol id="log"></ol>
      <button id="reset" type="button">Reset demo</button>
    </section>
    <p><small>The status revisions and controls are invented for teaching. A production client must get its authoritative result from its backend or SDK. This page does not authenticate messages, verify a payment, persist data, or contact a provider.</small></p>
  </main>

  <script>
    (() => {
      const checkoutId = 'demo-001';
      const messages = {
        pending: 'Waiting for server confirmation.',
        succeeded: 'The mock server reports that payment succeeded.',
        failed: 'The mock server reports that payment failed.',
        cancelled: 'The mock server reports that checkout was cancelled.',
      };
      const initial = () => ({ status: 'pending', revision: 0, accepted: 0, returned: false, closed: false, overdue: false });
      let state = initial();
      let timer;
      let generation = 0;
      let nextRevision = 0;
      const log = document.querySelector('#log');

      function record(text) {
        const item = document.createElement('li');
        item.textContent = text;
        log.append(item);
        while (log.children.length > 8) log.firstElementChild.remove();
      }

      function render() {
        const label = document.querySelector('#state');
        label.textContent = state.status;
        label.dataset.status = state.status;
        document.querySelector('#message').textContent = messages[state.status];
        document.querySelector('#revision').textContent = state.revision
          ? `Accepted server revision ${state.revision}; accepted updates: ${state.accepted}.`
          : 'No server update accepted yet.';
        const observations = [];
        if (state.returned) observations.push('Provider returned a success label.');
        if (state.closed) observations.push('Provider window was closed.');
        if (state.overdue) observations.push('Client wait limit was reached.');
        document.querySelector('#observation').textContent = observations.join(' ') || 'No provider event observed.';
      }

      function providerEvent(kind) {
        if (!['returned', 'closed', 'overdue'].includes(kind)) return;
        state[kind] = true;
        record(`Client event: ${kind}. Payment state remains ${state.status}.`);
        render();
      }

      function applyServerStatus(update) {
        if (!update || update.checkoutId !== checkoutId ||
            !Number.isSafeInteger(update.revision) || update.revision < 1 ||
            !Object.hasOwn(messages, update.status)) {
          record('Ignored an invalid update or a different checkout.');
          return false;
        }
        if (update.revision <= state.revision) {
          record(`Ignored duplicate or stale revision ${update.revision}.`);
          return false;
        }
        state.status = update.status;
        state.revision = update.revision;
        state.accepted += 1;
        record(`Server revision ${update.revision}: ${update.status}.`);
        render();
        return true;
      }

      function reset() {
        clearTimeout(timer);
        generation += 1;
        nextRevision = 0;
        state = initial();
        log.replaceChildren();
        record('Demo reset. No authoritative update received.');
        render();
      }

      function makeServerUpdate(status) {
        nextRevision = Math.max(nextRevision, state.revision) + 1;
        return { checkoutId, revision: nextRevision, status };
      }

      function delayedConfirmation() {
        clearTimeout(timer);
        const run = generation;
        const processing = makeServerUpdate('pending');
        const confirmation = makeServerUpdate('succeeded');
        applyServerStatus(processing);
        record('Queued a local confirmation for 1.2 seconds later.');
        timer = setTimeout(() => {
          if (run !== generation) return;
          applyServerStatus(confirmation);
        }, 1200);
      }

      document.querySelector('#provider-return').addEventListener('click', () => providerEvent('returned'));
      document.querySelector('#provider-close').addEventListener('click', () => providerEvent('closed'));
      document.querySelector('#wait-limit').addEventListener('click', () => providerEvent('overdue'));
      for (const button of document.querySelectorAll('[data-server]')) {
        button.addEventListener('click', () => applyServerStatus(makeServerUpdate(button.dataset.server)));
      }
      document.querySelector('#delay').addEventListener('click', delayedConfirmation);
      document.querySelector('#reset').addEventListener('click', reset);

      // Teaching/test hooks for this local simulation, not a production API.
      window.paymentDemo = Object.freeze({
        applyServerStatus, reset, delayedConfirmation,
        snapshot: () => ({ checkoutId, ...state }),
      });
      reset();
    })();
  </script>
</body>
</html>

Keep stale updates from replacing current ones

applyServerStatus() first checks the fictional checkout, revision, and state. It rejects an update for another checkout. Then it accepts only a revision greater than the last accepted revision.

Delivering revision 2 twice changes the display once. Delivering an earlier pending revision after a success cannot move the interface backwards. After the first delayed success, use the browser console to call window.paymentDemo.applyServerStatus({ checkoutId: 'demo-001', revision: 2, status: 'succeeded' }) again and see the duplicate rejected. A conflicting payload with the same revision is also rejected. This assumes each revision identifies one stable backend snapshot; a production service must define that contract and its recovery behavior.

A genuinely newer authoritative result can supersede an earlier state. The client does not invent a permanent terminal-state lock. Which transitions are valid belongs to the service that owns the payment lifecycle.

The accepted-update counter makes duplicate behavior visible. It does not prevent duplicate charges or implement backend fulfillment idempotency. Those require server-side controls; a browser counter cannot supply them.

Make delayed work belong to the current run

The delayed-confirmation button supplies a pending snapshot and reserves a separate success revision before scheduling its local timer. A later server button receives a larger revision even while that success is waiting. This models snapshots created in one order and delivered in another. Reset cancels it and advances a generation counter, so an earlier run cannot change the fresh demo. A queued result that is older than an already accepted revision is ignored when it arrives. MDN documents timer cancellation with clearTimeout().

Try returning from the provider, closing its window, and reaching the wait limit before confirmation. Try a newer server failure while a delayed success is queued. Try Reset before the timer fires. Inspect both the displayed result and the event log.

The local automated checks exercise those sequences, duplicate and out-of-order updates, invalid payloads, keyboard activation, and narrow-screen layout. They verify this fictional client only. They do not test a provider, SDK, webhook, actual charge, settlement, or production integration. Reloading restores the initial state because the page stores nothing.

Disclosure: AI generated the article and code example. The local simulation was checked with an automated browser; no human technical review or real-payment test is claimed.

A category filter should not reset an edited textarea

Rowan Hale — Thu, 08 Oct 2026 07:53:17 +0000

Imagine a page with two generated messages. You edit one, switch the category selector to hide it, and then switch back. The edited message should still be there.

This goes wrong when the category handler calls the same function that generates the starting text. That function may filter the cards correctly while also assigning new values to every textarea.

The fix begins with three separate concepts: the original template, the values used to personalize it, and the text a person has edited. Filtering changes visibility. Regeneration writes new draft text. Copy and download read the current draft.

Try the complete example

Save the following as example.html and open it in a browser. The messages and group names are fictional. No account, framework, network service, or build step is needed. Automatic copying depends on the browser allowing clipboard access; the example selects the text for manual copying if that write fails. MDN documents the clipboard security requirements.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Editable templates with a category filter</title>
  <style>
    * { box-sizing: border-box; }
    [hidden] { display: none !important; }
    body { margin: 0; background: #f5f7f6; color: #152f26; font: 17px/1.6 system-ui, sans-serif; }
    main { max-width: 900px; margin: auto; padding: 40px 20px; }
    h1, h2 { line-height: 1.2; }
    h1 { font-size: clamp(28px, 5vw, 42px); margin-top: 0; }
    h2 { font-size: 23px; }
    p { max-width: 68ch; }
    .panel { background: white; border: 1px solid #cbd9d2; border-radius: 12px; padding: 22px; margin: 22px 0; }
    .fields { display: grid; grid-template-columns: repeat(auto-fit, minmax(min(100%, 240px), 1fr)); gap: 18px; }
    label { display: block; font-weight: 650; }
    input, select, textarea, button { font: inherit; }
    input, select, textarea { display: block; width: 100%; border: 1px solid #92a99d; border-radius: 6px; padding: 10px; background: #fff; color: #152f26; }
    textarea { min-height: 140px; resize: vertical; margin: 8px 0; }
    button { border: 1px solid #235843; background: #235843; color: white; border-radius: 6px; padding: 9px 16px; cursor: pointer; }
    button:focus-visible, input:focus-visible, select:focus-visible, textarea:focus-visible { outline: 3px solid #dc9d19; outline-offset: 3px; }
    small { display: block; color: #486557; }
    #status { min-height: 2em; padding: 12px; border-left: 4px solid #235843; }
    .notice { font-size: 15px; }
  </style>
</head>
<body>
  <main>
    <h1>Editable templates with a category filter</h1>
    <p>Edit a draft, hide it with the category filter, then show it again. Your text stays intact. Regeneration replaces edits only when you click the button.</p>
    <p class="notice">This fictional example runs in your browser. It sends no messages, uses no analytics or storage, and loses its drafts when you reload or leave. Copy or download anything you want to keep.</p>

    <section class="panel" aria-labelledby="settings-title">
      <h2 id="settings-title">Template settings</h2>
      <div class="fields">
        <label>Group name<input id="group" value="Community team" maxlength="80"></label>
        <label>Meeting time<input id="time" value="Thursday at 6pm" maxlength="80"></label>
        <label>Category<select id="category"><option value="all">All categories</option><option value="events">Events</option><option value="volunteers">Volunteers</option></select></label>
      </div>
      <p id="regeneration-note" class="notice">Regenerate replaces manual edits in every draft, including hidden drafts. Changing the name or time alone leaves the current drafts intact.</p>
      <button id="regenerate" type="button" aria-describedby="regeneration-note">Regenerate drafts</button>
    </section>

    <p id="status" role="status" aria-live="polite">Example drafts are ready.</p>
    <section aria-label="Editable drafts">
      <article class="panel" data-id="event-reminder" data-category="events">
        <h2>Event reminder</h2>
        <label for="event-message">Your event draft</label>
        <textarea id="event-message" spellcheck="true"></textarea>
        <small data-count></small>
        <button type="button" data-copy>Copy event draft</button>
      </article>
      <article class="panel" data-id="volunteer-note" data-category="volunteers">
        <h2>Volunteer note</h2>
        <label for="volunteer-message">Your volunteer draft</label>
        <textarea id="volunteer-message" spellcheck="true"></textarea>
        <small data-count></small>
        <button type="button" data-copy>Copy volunteer draft</button>
      </article>
    </section>
    <button id="download" type="button">Download visible drafts</button>
  </main>
  <script>
    const templates = [
      { id: 'event-reminder', category: 'events', title: 'Event reminder', build: ({ group, time }) => `Hi ${group}, our meetup is ${time}. Please bring a notebook.` },
      { id: 'volunteer-note', category: 'volunteers', title: 'Volunteer note', build: ({ group, time }) => `Hi ${group}, can you help at our meetup ${time}? Reply with the task you can take.` },
    ];
    const group = document.querySelector('#group');
    const time = document.querySelector('#time');
    const category = document.querySelector('#category');
    const status = document.querySelector('#status');
    const cards = new Map(templates.map((template) => [template.id, document.querySelector(`[data-id="${template.id}"]`)]));

    function updateCount(card) {
      card.querySelector('[data-count]').textContent = `${Array.from(card.querySelector('textarea').value).length} characters`;
    }

    function filterCards() {
      for (const template of templates) {
        const card = cards.get(template.id);
        card.hidden = category.value !== 'all' && template.category !== category.value;
      }
    }

    function regenerate() {
      const values = { group: group.value.trim() || 'Community team', time: time.value.trim() || 'Thursday at 6pm' };
      for (const template of templates) {
        const card = cards.get(template.id);
        card.querySelector('textarea').value = template.build(values);
        updateCount(card);
      }
      filterCards();
    }

    function visibleDrafts() {
      return templates.filter((template) => !cards.get(template.id).hidden).map((template) => ({
        title: template.title,
        message: cards.get(template.id).querySelector('textarea').value,
      }));
    }

    category.addEventListener('change', () => {
      filterCards();
      status.textContent = 'Category changed. Your draft edits are kept.';
    });
    for (const input of [group, time]) {
      input.addEventListener('input', () => {
        status.textContent = 'New details are ready. Click Regenerate drafts to replace the current text.';
      });
    }
    document.querySelector('#regenerate').addEventListener('click', () => {
      regenerate();
      status.textContent = 'Drafts regenerated. Previous edits have been replaced, including edits in hidden drafts.';
    });
    for (const card of cards.values()) {
      const textarea = card.querySelector('textarea');
      textarea.addEventListener('input', () => updateCount(card));
      card.querySelector('[data-copy]').addEventListener('click', async () => {
        try {
          await navigator.clipboard.writeText(textarea.value);
          status.textContent = 'Current draft copied.';
        } catch {
          textarea.focus();
          textarea.select();
          status.textContent = 'Automatic copying is unavailable. The draft is selected for manual copying.';
        }
      });
    }
    document.querySelector('#download').addEventListener('click', () => {
      const text = visibleDrafts().map((draft) => `${draft.title}\n\n${draft.message}`).join('\n\n---\n\n') + '\n';
      const url = URL.createObjectURL(new Blob([text], { type: 'text/plain;charset=utf-8' }));
      const link = document.createElement('a');
      link.href = url;
      link.download = 'current-drafts.txt';
      document.body.append(link);
      link.click();
      link.remove();
      setTimeout(() => URL.revokeObjectURL(url), 1000);
      status.textContent = 'Download prepared from the current visible drafts.';
    });
    regenerate();
  </script>
</body>
</html>

Keep the category handler small

filterCards() only assigns card.hidden. It never assigns textarea.value, removes a card, or generates a replacement message. Each card keeps its stable data-id, so hiding it and showing it again retains the existing control and edited text. The hidden attribute controls rendering.

regenerate() has a separate button and a warning. That is the operation allowed to replace manual edits. It updates hidden cards too, so a draft does not quietly retain old personalization settings when it returns.

Read the text the person actually edited

The copy handler reads textarea.value at click time. The download handler reads the same current values and includes only visible cards. Neither regenerates the text before exporting it. The textarea value property represents its current contents.

The displayed count uses Unicode code points through Array.from(text).length. It is not a count of grapheme clusters, SMS segments, or billing units. JavaScript string iteration yields code points.

Check more than the initial render

Try these sequences:

Edit the event draft, filter to Volunteers, and return to Events. Your edit should remain.
Change the group name and click Regenerate drafts. The fresh template should replace the edit.
Edit again and click Copy event draft. Paste the result and compare it with the textarea.
Download visible drafts while Events is selected. The file should contain your final event text and exclude the volunteer draft.

The example keeps drafts only in the current page. Reloading restores the fictional defaults. If your interface removes controls or persists drafts, keep the edited text in state keyed by the same stable identifiers.

Disclosure: AI assisted the wording and code example.