Trello webhook delivery ordering guarantees absent in repeatable environments

Answer

To make a repeatable test environment you must treat the webhook as a fire‑and‑forget event stream and rely on Trello’s REST API for the authoritative order. The workflow is:

1. Persist every received payload keyed by action.id in a local store (DB, Redis, or a file).
2. On receipt, upsert; if the key already exists, ignore the duplicate.
3. Launch a background worker that periodically calls GET /1/actions?since=&limit=1000 for the board.
4. Merge the returned list into the store, ordering by action.date and action.id as a tie‑breaker.
5. In CI, after triggering the sequence of board actions, poll the worker’s store until all expected action.ids are present or a timeout expires.
6. Assert on the ordered list from the store, not on the raw webhook arrival order.

Likely Explanation

Trello’s webhooks are intentionally unordered. The only stable identifiers are action.id and action.date. The date field has second granularity, so two actions in the same second can still arrive out of order. Duplicate deliveries are common; deduplication must be performed on action.id.

Confirmed Facts

• The payload contains action.id (globally unique) and action.date (ISO‑8601, second resolution).
• GET /1/actions?since=… returns actions sorted by date ascending.
• Rate limits are 100 requests per 10 s per token; a 429 response includes a Retry-After header.
• Using a since cursor that is the last confirmed action.date + 1 ms avoids re‑fetching the same action.

Implementation Steps

1. Webhook Receiver

   // pseudocode
   function handleWebhook(req) {
     const payload = req.body;
     const id = payload.action.id;
     if (!store.has(id)) {
       store.set(id, payload);
     }
   }
   

2. Background Sync

   async function syncBoard(boardId) {
     let since = lastSyncedDate[boardId] || '1970-01-01T00:00:00Z';
     const res = await fetch(`https://api.trello.com/1/boards/${boardId}/actions?since=${since}&limit=1000`, {
       headers: { Authorization: `Bearer ${TOKEN}` }
     });
     if (res.status === 429) {
       const wait = res.headers.get('Retry-After') || 1;
       await sleep(wait * 1000 + Math.random() * 100);
       return syncBoard(boardId); // retry
     }
     const actions = await res.json();
     actions.forEach(a => store.set(a.id, a));
     if (actions.length) {
       lastSyncedDate[boardId] = actions[actions.length - 1].date;
     }
     setTimeout(() => syncBoard(boardId), 2000); // 2‑second cadence
   }
   

3. CI Assertion

   async function assertOrder(expectedIds) {
     const timeout = Date.now() + 30000; // 30 s
     while (Date.now() < timeout) {
       const ids = store.getOrderedIds(); // sorted by date
       if (expectedIds.every((id, i) => ids[i] === id)) {
         return true;
       }
       await sleep(500);
     }
     throw new Error('Timeout waiting for expected actions');
   }
   

Rate‑Limit‑Safe Verification

• Keep the sync cadence to 1–2 s per board; this stays well below the 100/10 s quota.
• Use the Retry-After header and exponential backoff (max 60 s) when a 429 is received.
• Cache the since cursor so that a retry resumes without re‑fetching already seen actions.

Missing Diagnostic Detail

To fine‑tune the sync cadence for your specific test workload, could you share the average number of actions per board per minute that your CI pipeline generates?