Webhooks for some delete operations are not sent. #3907

New Issue

OVERLORD · 2026-02-05T07:49:57+03:00

OVERLORD commented

2026-02-05 07:49:57 +03:00

Originally created by @toras9000 on GitHub (Jul 9, 2023).

Describe the Bug

When performing entity deletion in the browser, webhooks are not sent for some operations.
Specifically, revision_delete, user_delete, api_token_delete, and webhook_delete.

When these operations are performed with webhooks set for the operations, HTTP status 404 seems to be returned.
If no webhook is set, the response is normal.

Steps to Reproduce

Add a Webhook.
- It does not seem to matter whether the endpoint address is valid or invalid.
- Turn on 'All system events'.
Perform operations corresponding to the problematic webhook events described above.
- Webhook does not reach the endpoint.

Expected Behaviour

Webhook is sent.

Screenshots or Additional Context

No response

Browser Details

No response

Exact BookStack Version

v23.06.1

PHP Version

No response

Hosting Environment

Docker image, lscr.io/linuxserver/bookstack:version-v23.06.1

Originally created by @toras9000 on GitHub (Jul 9, 2023). ### Describe the Bug When performing entity deletion in the browser, webhooks are not sent for some operations. Specifically, `revision_delete`, `user_delete`, `api_token_delete`, and `webhook_delete`. When these operations are performed with webhooks set for the operations, HTTP status 404 seems to be returned. If no webhook is set, the response is normal. ### Steps to Reproduce 1. Add a Webhook. - It does not seem to matter whether the endpoint address is valid or invalid. - Turn on 'All system events'. 1. Perform operations corresponding to the problematic webhook events described above. - Webhook does not reach the endpoint. ### Expected Behaviour Webhook is sent. ### Screenshots or Additional Context _No response_ ### Browser Details _No response_ ### Exact BookStack Version v23.06.1 ### PHP Version _No response_ ### Hosting Environment Docker image, lscr.io/linuxserver/bookstack:version-v23.06.1

OVERLORD added the 🐛 Bug 🏭 Back-End labels 2026-02-05 07:49:57 +03:00

OVERLORD closed this issue

2026-02-05 07:50:00 +03:00

OVERLORD commented

2026-02-05 07:50:06 +03:00

@toras9000 commented on GitHub (Jul 12, 2023):

This may not be necessary, but I have done some research and will describe it.

I think the problem may be in the DispatchWebhookJob dispatch.
Does the deleted $detail cause problems with serialization when queuing?

In the case of page revisions, it would appear that simply changing the order of the following would work. (at least on the surface.)
(PageRevisionController.php)

$revision->delete();
Activity::add(ActivityType::REVISION_DELETE, $revision);

@toras9000 commented on GitHub (Jul 12, 2023): This may not be necessary, but I have done some research and will describe it. I think the problem may be in the DispatchWebhookJob dispatch. Does the deleted $detail cause problems with serialization when queuing? In the case of page revisions, it would appear that simply changing the order of the following would work. (at least on the surface.) (PageRevisionController.php) ``` $revision->delete(); Activity::add(ActivityType::REVISION_DELETE, $revision); ```

OVERLORD commented

2026-02-05 07:50:11 +03:00

@ssddanbrown commented on GitHub (Jul 12, 2023):

Thanks for reporting @toras9000, Can confirm, did indeed seem due to Laravel's smart serialiszation and handling of models when in the queue, where it'd attempt to re-fetch models from the database on queue job run.

I've instead changed how the job is handled, so now the webhook data is formatted on job creation, and that data is stored with the queue job instead of the model itself.

I've always put the activity logs after the actual delete action, just to ensure that activities are not logged in the event the deletion fails, so I didn't want to switch that up.

Patch in a83150131a, to be part of the next patch release.

@ssddanbrown commented on GitHub (Jul 12, 2023): Thanks for reporting @toras9000, Can confirm, did indeed seem due to Laravel's smart serialiszation and handling of models when in the queue, where it'd attempt to re-fetch models from the database on queue job run. I've instead changed how the job is handled, so now the webhook data is formatted on job creation, and that data is stored with the queue job instead of the model itself. I've always put the activity logs after the actual delete action, just to ensure that activities are not logged in the event the deletion fails, so I didn't want to switch that up. Patch in a83150131a900a4ec8175e87da323eda254fab86, to be part of the next patch release.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#3907