Cronologia e risoluzione dei problemi
Ogni richiesta che giunge a un webhook viene registrata, sia che venga accettata sia che venga rifiutata. La cronologia è il primo posto in cui consultare quando qualcosa non si è verificato.
Lettura di un’invocazione
Aprire la sezione "Cronologia" e fare clic su una voce. Verranno visualizzati l'ora e la data, lo stato, il mittente, la durata, il payload, le intestazioni della richiesta (mascherate), la stringa di query e, in caso di errori, il messaggio di errore e ogni tentativo di riprova.
| Stato | Significato |
|---|---|
| In sospeso | Accettato e inserito in coda, non ancora consegnato a Shopify Flow |
| Successo | Shopify Flow ha accettato il trigger |
| Non riuscito | Consegna non riuscita in modo definitivo: la pagina dei dettagli ne illustra il motivo |
La colonna "Invoked by" indica la provenienza di una chiamata: User (un sistema esterno), Flow (un'azione di Shopify Flow che richiama il webhook), Test (il pulsante "Test") o CURL.
I rifiuti e il significato di ciascuno di essi
Una richiesta respinta non raggiunge mai Shopify Flow. Il corpo della risposta contiene un codice di errore leggibile dal sistema (code):
| Codice | HTTP | Cosa è andato storto | Correzione |
|---|---|---|---|
webhook_not_found |
404 | Codice breve sconosciuto | Verifichi l'URL; è possibile che il webhook sia stato eliminato |
webhook_disabled |
400 | Il webhook è disattivato | Attivatelo nella pagina dedicata ai webhook |
unauthorized |
401 | Token mancante o errato | Verifichi il token e il nome dell'intestazione |
missing_signature |
401 | Modalità HMAC, senza intestazione di firma | Invii l'intestazione della firma prevista dal Suo preset |
invalid_signature |
401 | La firma non corrispondeva | Verifichi che il segreto di firma sia corretto e che il contenuto non sia stato alterato durante il trasferimento |
auth_not_configured |
401 | La modalità "Auth" è impostata, ma non è stato salvato alcun token | Salvare un token sul webhook |
invalid_json |
400 | Il corpo del messaggio non è un JSON valido | Invii un JSON valido oppure imposti il Content-Type corrispondente al contenuto effettivo del corpo del messaggio (vengono letti anche i dati dei moduli e l'XML) |
invalid_body |
400 | Non è stato possibile leggere un modulo o il corpo XML, oppure il corpo è il valore letterale null |
Inviare un oggetto JSON oppure un corpo del messaggio che corrisponda al suo Content-Type |
mapping_field_missing |
400 | Nel payload manca un campo mappato | Inviare il campo oppure annullarne l’associazione |
unexpected_fields |
400 | Il corpo presenta campi che non sono mappati | Mappatele, rimuovetele oppure attivate l'opzione "Consenti corpo della richiesta personalizzato" |
ip_not_allowed |
403 | L'indirizzo del chiamante non figura nell'elenco degli indirizzi IP autorizzati del webhook | Si veda Elenchi di indirizzi IP autorizzati |
invalid_proxy_signature |
401 | L'indirizzo proxy dell'app è stato richiamato direttamente anziché tramite il dominio del Suo negozio | Utilizzi l'URL del webhook esattamente come indicato dall'app - si veda CORS, l'URL del proxy dell'app e le richieste del browser |
payload_too_large |
413 | Shopify Flow payload superiore a 50 KB | Riducete la quantità di dati inviati oppure disattivate i pulsanti di attivazione/disattivazione della richiesta di dati |
quota_exceeded |
400 | Limite del piano raggiunto | Si veda Piani e utilizzo |
Live Request Inspector
Mentre avete un webhook aperto nell’editor, l’inspector mostra le richieste in arrivo in tempo reale, comprese quelle rifiutate, con l’indicazione del motivo. Questo è di gran lunga il modo più veloce per eseguire il debug di un mittente: inviate una richiesta e osservate la sua destinazione.
Anche i duplicati eliminati compaiono in questa sezione, contrassegnati come tali - si veda Protezione contro le consegne duplicate.
Replay
Qualsiasi invocazione precedente può essere riprodotta dalla relativa pagina dei dettagli. La riproduzione invia nuovamente lo stesso payload tramite lo stesso webhook.
Due cose per cui è particolarmente indicato:
- Creazione di un workflow in Flow. Registrare gli eventi sul trigger Webhook, quindi riprodurre un vero Eseguite la chiamata in modo che Shopify Flow apprenda i nomi effettivi dei campi.
- Ripristino a seguito di un’interruzione del workflow. Si corregga il workflow, quindi si rieseguano gli eventi che sono stati eseguiti sebbene fosse sbagliato.
Le repliche sono contrassegnate come tali nella cronologia e non vengono conteggiate ai fini del Suo piano.
Situazioni comuni
Le chiamate arrivano, ma il workflow non viene eseguito. Quasi sempre il problema è legato alla condizione relativa all’ID del webhook. Un workflow con trigger webhook riceve eventi da tutti i webhook di cui disponete, pertanto richiede una condizione che corrisponda all’ID specifico del webhook - consultate Creare il Suo primo webhook.
Il workflow viene eseguito due volte. Ciò può significare che due flussi di lavoro utilizzano il trigger Webhook senza condizioni distinte, oppure che il mittente sta effettuando un nuovo tentativo. La cronologia Le indica quale delle due ipotesi sia corretta: due voci indicano che sono pervenute due richieste. AttiviProtezione contro le consegne duplicate (Rilevamento dei tentativi multipli).
Non risulta assolutamente nulla nella cronologia. La richiesta non ci è mai pervenuta. Verifichi l’URL e il codice abbreviato e si assicuri che il mittente non presenti errori TLS o DNS dalla sua parte.
Lo stato rimane bloccato su “In sospeso”. La consegna viene riprovata con un meccanismo di backoff; in caso di errore permanente, lo stato passa a “Fallito” con l’indicazione del motivo. Se lo stato rimane “In sospeso” per un periodo insolitamente lungo, si prega di verificare status.codecreationlabs.cloud.