When a failed webhook delivery prevents it from being delivered again (with different args).

[eri-trabiccolo]

Reproduction Steps

• Create a webhook
• trigger it and verify it works fine (e.g. check logs)
• now simulate a failure during the delivery, e.g. a fatal here:
  https://github.com/gocodebox/lifterlms-rest/blob/1.0.0-beta.16/includes/models/class-llms-rest-webhook.php#L32
  (basically after that the pending_delivery field has been set to 1)
  or just set the value directly in the db :)
• trigger the same webhook

Expected Behavior

• I would expect the second webhook to be delivered

Actual Behavior

• The second webhook is not delivered.
  This is because the pending_delivery is set to 1 in the db for that webhook, and then should_deliver() returns false:
  https://github.com/gocodebox/lifterlms-rest/blob/1.0.0-beta.16/includes/models/class-llms-rest-webhook.php#L421

Error Messages / Logs

n/a

System Information

System Report

LifterLMS Rest 1.0.0-beta.16

Browser, Device, and Operating System Information

n/a

Related User Information

HS-140845

Solution here would be to not store the pending_delivery and, of course, not relying on this.
I've investigated a little bit into this and IF (as it seems) the reason why we use it is to avoid delivery duplicate within the same request, then we should use a different approach, e.g. looking at our inspiration:
woocommerce/woocommerce@b262ac8#diff-8971231b02d400aadd63a60794ca17128d5dd8e9ed670745f6785ec8d9425128

Additionally, the same inspiring software, uses the pending_delivery only for deciding whether or not a delivery ping should be performed: sends the delivery ping only if pending_delivery is set to 1 (and this value is set on the webhook creation).

We use a different approach to determine it, and already don't rely on the pending_delivery property.
(I think we could even get rid of it...)

[thomasplevy]

Thumbs up <3