Lack of interest Improve Stability of the Deferred System

[pegasus]

While looking into this issue, I became aware of some aspects of the Deferred system in XenForo which I feel should be addressed, as it will help prevent future problems like this from being so bad: https://www.vaultwiki.org/articles/160/

Please note that the linked issue only occurs because of a workaround intended to "improve" the behavior of XenForo's Deferred system. If XenForo's deferred system were already like this, potentially dangerous workarounds like those would not even be attempted. Even if such a workaround is still attempted, XenForo will now be smart enough to handle the situation.

#1 Basically, if an add-on adds a manual entry to the defer table, there should be a column that associates the entry with the add-on. This way:
1. If the add-on is disabled, the deferred entry is not run.
2. If the add-on is disabled, the deferred entry is not required to have code to skip itself and allow itself to be removed from the queue (for data integrity purposes, the task should still be queued on add-on re-enable).
3. The add-on will not need to workaround #2, as a failure during a workaround could result in an infinite deferred.php attack.

Once the deferred system knows add-on IDs, it will only run deferred tasks for active add-ons. If there are no more tasks from active add-ons, there is no more next-run time. The next-run time can be recalculated whenever an add-on is enabled or disabled.

#2 Secondly, don't automatically remove a task before it runs! Even if the task fails, it may be necessary for it to run eventually. Instead of removing the task before running, place a lock on the task so it is not valid for next-run until the current run completes (I recommend using a locktime field, so you can log tasks as failed if they have been locked for a long time). After a successful run, instead of adding a new task if 'moreDeferred', simply release the lock.

These simple changes will increase the solidness of the deferred system and help to mitigate situations like those linked above where XenForo unknowingly launches a DDoS attack against itself, or if the deferred task is coded in such a way that still makes it possible, that the attack can be stopped simply by disabling the add-on.

 

[AlexT]

I am not fully convinced I understand the issue at hand (something about deferred tasks not properly cleaned from the task queue?)... Still, I fail to see how this is related to an "attack" or a "DDoS".

 

[pegasus]

In the particular case I quoted: When a task fails and is not properly cleaned from the queue, an infinite loop reattempting the task can be started. By only looking at your access logs, you would assume that you were under a DDoS attack, because you see multiple IP addresses making requests to deferred.php in quick succession (and forever, until you manually clean out your xf_defer table).

This only happens if the task itself was written a certain way, and the way the task is written is not XenForo's fault. I only made note of it here because it was while debugging this problem that I realized it would have been easier to deal with if disabling the add-on would have had an effect on the deferred system.

But the way XenForo is currently setup, disabling the add-on does not prevent the add-on's deferred tasks from running in the future. I originally felt this aspect should be considered a bug, but it was moved to an improvement request.

Thus my improvement request was as follows:
- Allow a Deferred task to be associated with an add-on at the database level
- deferred.php should only run tasks that are associated with enabled add-ons
- tasks for inactive add-ons should remain in the queue meaninglessly, or until the add-on is enabled again