Views saved search notification does not work preoperly

I've also been having trouble with notifications and I discovered a bug that was causing it (at least in my case). I'm not sure if yours is related, but there are already several issues open about the behavior of the notifications, so I didn't want to open yet another. My experience was that notifications seemed to work intermittently--I would sometimes get notifications, but not for all new nodes.

In notifications_views_savedsearches_cron(), each subscription's view is executed and the results are compared with a cache of the previous execution of it. The flaw seems to be that $view->execute() is called directly after loading it and applying the exposed input (without setting any other parameters), which I believe executes the default display. However the default display doesn't necessarily match what the user saved and could yield a resultset that looks nothing like the user's preferences. It may contain different filters, or additional arguments.

That may or may not have contributed to the erratic behavior of the notifications, but I am certain that the view's default paging did. In my case, the default display and the display that was saved both had paging turned on and items-per-page set to 12. Each time cron executed the view, only the first 10 results were returned--why 10 and not 12 I can't say, but examining the view object before applying any changes to it shows that $view->pager['items_per_page'] = 10 (also $view->pager['user_pager'] = FALSE, but that doesn't seem to factor into the result). So at each cron run, only the first 10 records are ever examined and only if a new record happened to fall within those first 10 (unlikely in my situation) would a notification be sent.

The attached patch fixes this in version 6.x-1.0-beta4, however there is some additional work that is advisable in implementing it. I considered writing an update hook to handle the cleanup, but decided against it because the outcome might be undesirable for some. The problem is that for any existing subscriptions, only records which appeared in the first 10 results would ever have been cached. There may be more than 10 records in the cache (by cache I'm referring to the notifications_views_savedsearches table), but if like mine your full resultset was hundreds of records, the majority of the remaining several hundred wouldn't be in the cache (that is, their absence is an indicator that they'd been seen by the user, and therefore would be considered new). So the first notification that went out after implementing this fix might contain several hundred or more records. That might be undesirable for many reasons, not least of which is performance. For my situation, it was acceptable to just empty the notifications_views_savedsearches table and start fresh. This caused the first cron run to treat all subscriptions as new, caching all matching nodes and sending no notification. Subsequent cron runs will result in the desired notification behavior on any matching new nodes.

May i ask for a clarification? Does the above patch in #2 aid in Notifications 4.0 compatibility as mentioned in #1 or is that a completely separate from what that patch fixes?