{"id":40,"date":"2026-09-08T10:00:00","date_gmt":"2026-09-08T08:00:00","guid":{"rendered":"https:\/\/www.phabdev.it\/blog\/?p=40"},"modified":"2026-08-30T02:34:23","modified_gmt":"2026-08-30T00:34:23","slug":"casi-maledetti-diari-di-uninfrastruttura-ecommerce","status":"publish","type":"post","link":"https:\/\/www.phabdev.it\/blog\/2026\/09\/08\/casi-maledetti-diari-di-uninfrastruttura-ecommerce\/","title":{"rendered":"Casi Maledetti: Diari di un’Infrastruttura eCommerce"},"content":{"rendered":"

Tre storie reali di bug invisibili, perdite finanziarie silenziose e ingegneria deterministica nel backend operativo.<\/em><\/p>\n

\n

1. Il bug invisibile di WooCommerce: quando i webhook smettono di parlare (e come evitarlo)<\/h2>\n

Luned\u00ec mattina, ore 11:30. Il reparto logistico telefona in amministrazione: “Come mai oggi non ci sono ordini da preparare? \u00c8 tutto fermo da stamattina”.
\nL’eCommerce Manager apre la dashboard dello store WooCommerce: 23 ordini ricevuti e pagati regolarmente nelle ultime tre ore. Eppure, sul gestionale l’elenco \u00e8 vuoto. Nessun server \u00e8 caduto, non ci sono errori nei log di sistema, la CPU \u00e8 al 5% e il database risponde in millisecondi. Tutto sembra apparentemente normale.<\/p>\n

Questo \u00e8 il guasto silenzioso classico delle integrazioni WooCommerce trascurate.<\/p>\n

La Causa: La disattivazione silenziosa di WooCommerce<\/h3>\n

Quando un ordine viene completato, WooCommerce invia una notifica HTTPS (webhook) al sistema di destinazione. Se il server dell’ERP o della logistica ha un micro-ritardo temporaneo (ad esempio un timeout di rete di 5 secondi dovuto a un sovraccarico momentaneo), la chiamata fallisce.
\nWooCommerce riprova a consegnare il webhook. Se riscontra pochi fallimenti consecutivi, attiva una funzione nativa devastante: imposta lo stato del webhook su “disabled” nel database, in silenzio, senza avvisare nessuno.<\/strong><\/p>\n

Da quel secondo in poi, l’integrazione smette di funzionare. Il merchant lavora alla cieca finch\u00e9 un magazziniere non si accorge del vuoto anomalo sulle linee di spedizione.<\/p>\n

La Soluzione: Riconciliazione asincrona + Watchdog attivo<\/h3>\n

Un’integrazione professionale non si basa sulla speranza che la rete e i webhook funzionino sempre. Si progetta partendo dal presupposto che prima o poi falliranno.<\/p>\n

Per risolvere questo problema alla radice, la nostra infrastruttura PHABDEV applica tre livelli di sicurezza:<\/p>\n

    \n
  1. Il Poller di Sicurezza<\/strong>: Accanto al webhook in tempo reale, facciamo girare un processo di polling periodico controllato da un cursore temporale (WOO_LOOKBACK_MIN<\/code>). Se il webhook salta, il poller recupera l’ordine mancante al ciclo successivo.<\/li>\n
  2. La query corretta su modified_after<\/code><\/strong>: Molti sviluppatori usano il parametro after<\/code> (data di creazione dell’ordine) per interrogare le API di WooCommerce. Questo \u00e8 un errore grave: se un ordine nasce in stato “pending” (non pagato) e viene pagato dopo tre ore, il poller con filtro sulla data di creazione lo salter\u00e0 per sempre. Usiamo rigorosamente modified_after<\/code>, cos\u00ec ogni cambio di stato riporta l’ordine nel mirino della sincronizzazione.<\/li>\n
  3. Il Watchdog delle API<\/strong>: Un monitor interno controlla ogni minuto il timestamp dell’ultimo ciclo riuscito di ciascun poller (ultimoOkMs<\/code>) e lo stato del webhook WooCommerce. Se il webhook passa da active<\/code> a qualsiasi altro stato, il Watchdog notifica immediatamente il team tecnico su Telegram, indicando la scheda di ripristino del Runbook prima che il cliente finale o la logistica avvertano il disservizio.<\/li>\n<\/ol>\n
    \n

    2. GID vs ID: Come Shopify ha quasi sdoppiato la contabilit\u00e0 di un merchant<\/h2>\n

    Nel collaudo end-to-end di una nuova integrazione custom per un importante merchant Shopify, l’ordine di test #1003 \u00e8 apparso due volte nell’anagrafica del gestionale aziendale. Due righe identiche, due fatture emesse con protocolli consecutivi, magazzino scalato del doppio rispetto alla merce realmente venduta.<\/p>\n

    L’integrazione possedeva un registro di idempotenza robusto per impedire le doppie scritture. Eppure, la barriera di sicurezza era stata aggirata.<\/p>\n

    La Causa: Il doppio formato degli identificativi di Shopify<\/h3>\n

    Andando a ispezionare i log dei payload in ingresso, abbiamo scoperto l’origine del conflitto. L’architettura utilizzava due vie di ricezione per garantire l’alta affidabilit\u00e0: i webhook in tempo reale (REST) e un poller GraphQL Admin API per la riconciliazione notturna.<\/p>\n