As designed add-on is_processing issues

[Xon]

Affected version

2.0.2

XenForo 2 adds an is_processing to track if an add-on is being installed or not. However this flag is nasty in that it leaves the add-on is a half disabled state, which during an upgrade means all template modifications and templates still apply but none of the backing code is running.

Worse, there are no UI indicators that an add-on is in is_processing state and thus unusable.

If the upgrade process blows up due to an installer step failing, the install/upgrade is aborted but the is_processing flag left in place.

A common example of the install processing failing is php timeouts during an install/upgrade step, XF's installer simple may not be able to run cleanup code. This can happen when adding an index or a column takes a lot longer than expected. Another example would be php version differences which can (depending on php's version) result in the script halting.

Would it be possible for an addon.json file to dictate how the is_processing flag is applied?

 

[ToyBoxOrphan]

I'm curious if this is related to a problem I've had. When I first got XF2 (brand new to XF so did not know what to expect), I "installed" a bunch of add-ons. They worked on the forum, but in the admin cp, they never said they were installed. They continued to be listed as Installable Add-ons. I did not know this was incorrect behavior because I've never used XF before. It wasn't until I installed a 4th add on that it actually correctly installed. I went back and got the others installed correctly, but this didn't seem to have anything to do with anything I was doing. Sometimes when an add on installs, it just stops and I get a message that seems to indicate I'm not connected and I have to hit refresh to finish the installation. This always leads to an installation that doesn't really happen. The big problem I can see is that it obviously does stuff to my forum when this happens (because I went a week without knowing these add ons weren't really installed...they all worked on the front end as expected), but I don't have any option to un-install them or disable them or look at templates. This happens about 85% of the time for me, but it did happen to my other admin once too.

 

[Mike]

Generally speaking, this flag is very much a necessary evil as not having it can cause specific situations where an add-on can't be installed, upgraded or uninstalled due to specific orders being required.

Any situation that occurs that triggers an error during add-on installation, upgrade or uninstallation will generally need the add-on author to provide some sort of guidance towards resolution. We now surface when an add-on is in this potentially inconsistent state to make it clear what is happening, along with providing a warning that this can suppress errors (intentionally) or cause unexpected behavior. For step-based add-on actions, we will expose the last action/step completed which can help add-on authors know where the error occurred. (Any errors triggered by the add-on action process itself should always be logged as well.) If it proves needed, in the future, we may be able to surface a more direct way to "continue" a broken add-on action, though that may need more extensive testing.

However, beyond that, I don't see us allowing add-ons to control how the is_processing flag works or is applied. So in that regard, towards the final question posted, I will say this is "as designed". I suppose a specific add-on may be able to trigger something in their code, though I wouldn't recommend it.