Issue: [4.1.2] Watched page notifications are not firing on new edits

In AdminCP > Setup > Options > VaultWiki: Notifications, is "Notify subscribers when pages are modified" checked?

Notify subscribers when pages are modified: Checked (Yes)

Enable wiki subscriptions: Checked (Yes)

---

EDIT 1:
Page tested is a standard wiki page.

Enable feed subscriptions: Checked (Yes)

The following other notification admin options are off but shouldn't apply for this test case:
Enable book subscriptions: Unchecked (No) - Book content type is disabled
Enable category subscriptions: Unchecked (No) - Unsure why I unchecked this one but should be irrelevant to the standard page testing.

EDIT 2:
Have since enabled book and category subscriptions and repeated edit test on a 2nd account watched page. Same result with no alert or push notification.

Check the receiving user's profile settings, Preferences > Receive a notification when someone…
- Make sure that "Updates watched wiki content" is checked

Yes, alert preferences are correct.

Updates watched wiki content:
Alert: Checked (Yes)
Push: Checked (Yes)

Every choice under 'Receive a notification when someone...' is checked for Alert and Push.

I have since conducted further tests on a separate copy of XF + VW, this time from within my local home network running XF 2.1.x and VW 4.1.2b002. Admin option 'Notify subscribers when pages are modified' is checked. Every choice under Account preferences 'Receive a notification when someone...' is checked for Alert. Push is disabled here.

1. With Area watch options enabled on first account and set to 'Alert only' for 'New edits', 'New child pages', 'New edits to child pages'. No alert was issued for a child page edit (Edited by second account).
2. With Page watch options enabled on first account and set to 'Alert only' for 'New edits'. No alert was issued for a page edit (Edited by second account).
3. With both Area and Page watch options enabled together for user 1, the outcome for user 2 page edits was the same as above.

Opening table xf_user_alert, there is only a single row for content_type 'vwpage' and that is with action 'insert' from when I created a test page.

I have confirmed the behavior you describe. I am not sure if it is limited to notifications, but when certain actions queue up deferred tasks (such as a task to send out notifications), some tasks are either failing to make it to the queue, or are getting deleted almost instantly. I will let you know as soon as I have more information.

I have identified the issue. The fix will be included in the July patches this weekend.

The problem is isolated to XenForo installations running VaultWiki 4.1.0 RC 2 or later. In this version, VaultWiki began allowing XenForo to fully handle storage of the IP address data for its content.

When queuing the notifier task, VaultWiki includes a copy of the content, including joined table data, and hands that copy to the queue (in case the content is altered significantly before all notifications complete). This copy is JSON-encoded. However, XenForo encodes IP address data in a binary format, and binary data is not compatible with JSON, so the task ends up queued without a reference to the trigger content. When the task executes, since no content triggered it, there are no people watching to alert.

This problem is not isolated to edit alerts, but also the last-update column in content lists, certain deleted content, and others. Some of these effects, such as orphaned content, are possible to correct in a future upgrade script; for others, the data is lost (not possible to send out alerts, since the trigger event has passed).