If you only see this one time in your logs, then this doesn't seem like a bug in VaultWiki.
There are a number of ways I would expect this to happen:
- Manually disabling VaultWiki's listener on templater_setup
- Another add-on has a listener on templater_setup that returns false
- The following race condition in XenForo 2:
In XenForo 2, when an add-on is currently disabled and then enabled:
- XenForo changes the add-on's active state and saves it.
- XenForo queues to rebuild listeners closer to the end of the current request.
- XenForo saves a new job where template modifications related to the add-on will be compiled into templates.
- Some time passes, while the request performs some other tasks.
- In this same request, the queued listener rebuild finally executes.
Between #3 and #5, it is possible for another user to access the forum. At this moment, the user will run the template-modification job. In theory, the job can complete before #5 above. If a third user accesses the forum in this period, the user can view the add-on's template modifications even though the add-on's listeners are not public yet.
In this case, the third user will see this error message if the add-on's template modifications use template functions that are added by the same add-on (which seems reasonable to me). Once #5 runs, the error will no longer occur.
There is really nothing VaultWiki can do about this rare situation. I'm not sure there is much XF devs can do about it either, although you may wish to raise the situation with them, since it is related to the way add-on activations are designed. In general I think we just have to accept that while rebuilds are part-way completed, weird things can happen.