Hallo @Support,
Webhook-Aktionen stehen im Tagebuch immer als versendet, egal ob es wirklich funktioniert hat, oder aber man sinnlosen Text als URL in die Webhook Aktion eingibt, der DNS-Name nicht auflösbar ist, der Host nicht erreichbar ist oder das Ziel Fehlerreturncodes zurückliefert.
Das Tagebuch muss hier auch verschiedene Fehler kenntlich machen, um seinen Zweck zu erfüllen.
Gruß
Flo
Das ist dann eher ein Feature Vorschlag.
Gruß Andreas
Guten Abend,
einen Status von einen Webhook zu Interpretieren, würden doch dem Standard des Webhook widersprechen denke ich, denn es wurde als einfaches Kommunikations Werkzeug erschaffen ohne ein Polling zu erwarten.
Bei einem Einsatz von einem Webhook, hatte ich noch nie eine Ergebnis Protokoll erwartet 
, aber kann mich diesbezüglich auch täuschen. 
Einfach, aber dennoch zuverlässig.
Ich fordere hier ja nicht, dass die komplette Response ausgewertet wird und zur Verfügung steht, sondern „nur“, dass im Tagebuch ersichtlich ist, ob der Webhook erfolgreich war oder nicht.
Denn genau zu diesem Zweck ist das Tagebuch ja da. Um Transparenz zu schaffen.
Das ist aktuell nicht der Fall. Alle Webhooks werden im Tagebuch als erfolgreich deklariert.
Nun kann man sich natürlich streiten, was alles erfolgreich ist und was nicht. Die technische Sicht und die Ansicht des Anwenders sind da durchaus unterschiedlich.
Daher wäre es das einfachste/unmissverständlichste, die tatsächlichen Returncodes im Tagebuch anzugeben.
Denn wenn homee Mal wieder die WLAN-Verbindung verliert, zu behaupten, der Webhook wurde gesenden, ist glatt gelogen.
Ich hab es in einem Feature-Vorschlag verschoben.
danke nein. ich sehe es erst Mal weiterhin als Fehler an.
Der Fehler ist zwar nicht im Coding, sondern vorher schon im Design. Aber es bleibt ein Fehler. Denn aktuell stellt homee das Verhalten nicht richtig dar.
Wenn die DNS-Auflösung nicht funktioniert oder homee kein funktionierendes WLAN hat, wird auch nichts gesendet.
Ich geb euch Recht, dass der Lösungsvorschlag auch Returncodes anzugeben eher ein Feature Request ist.
Aber das ist ja auch nur ein Vorschlag, um den Fehler zu korrigieren.
Dann sind wir alle unterschiedlicher Meinung als Du
Es macht einen Unterschied ob Du was abfeuerst oder ob Du abfeuerst und dann ein Ergebnis erwartest. Designed ist es als abfeuern (wahrscheinlich über CURL)
genau, es macht einen Unterschied, ob ich das Webhook-Komando „abfeuere“ oder einen Webhook „sende“.
Senden impliziert, zumindest für mich, dass der Webrequest den homee zumindest verlassen hat.
btw: Push- und Mail-Benachrichtigungen werden afaik auch als „konnte nicht versendet werden“ gekennzeichnet
Das tut er doch auch, selbst wenn wie Du auch schreibst
Dir geht es doch viel mehr darum , das homee bestätigt, dass der webhook beim Empfänger auch angekommen ist, oder nicht?
Es ist kein Bug, es ist ein Feature Request (Feuern vs. Feuern und Ergebnis). Die Diskussion bringt aber weder Dir noch mir was, deshalb bin ich hier raus.