Design issue Class extensions/extra fields for Entity are ignored on XenForo upgrade for reaction cache rebuild

Jake B.

Jake B.

Well-known member
Upon upgrading from 2.1.0 -> 2.1.1 the reaction cache is losing all of our extra data that we add. I haven't tracked down the exact cause yet, but here is what I currently believe is happening:

For some reason, I suspect that our class extension on the Reaction entity is being ignored which means that when \XF\Repository\Reaction::getReactionCacheData runs $reaction = $reaction->toArray(); is excluding our fields.

Still doing some digging into it, so this is mostly speculation. Will update this thread with more details as I come up with them
 
Might be happening because we rebuild the reaction cache in the XF:CoreCacheRebuild job, but theoretically I don't think that should be happening while the extensions/listeners are still disabled.

Does this happen with both web and CLI upgrades?
 
Ok, this is kind of obvious now I've thought about it some more.

When you perform an upgrade, various rebuild jobs are executed. They are executed by the installer system itself and, for obvious reasons, we don't allow add-on code to run there.

I'm going to leave this open, but for now I'd strongly recommend exploring a different approach. This may mean maintaining your own cache separately and using that, rather than relying on the default XF cache which won't include your extended data.
 
That's one option, but even that isn't as simple as it sounds. How does that event get fired? The upgrade system knows when XenForo has finished upgrading, but that's still the upgrade system where we don't fire events/extensions. There's no single place that you hit on the front end or Admin CP after upgrading XF where we can conclusively indicate that the upgrade has finished.

There's possibly many ways it can be done, but I'm struggling to come up with something elegant.

Something more elegant than this, for example...

1. Create a class extension of XF\Job\UpgradeCheck
2. Extend the run method and call the reaction rebuild there.

That job is run after every upgrade (or master data rebuild). It's the first thing that should run and it would run in the context of Admin/front end depending on where the user hits first.

Of course I'm having thoughts now of a built in PostUpgrade job that we can call and can just be extended but it just seems meh.
 
Chris D said:
Something more elegant than this, for example...

1. Create a class extension of XF\Job\UpgradeCheck
2. Extend the run method and call the reaction rebuild there.

That job is run after every upgrade (or master data rebuild). It's the first thing that should run and it would run in the context of Admin/front end depending on where the user hits first.
Click to expand...

I assume this will be called the first time a user accesses the site even if you run the upgrade from CLI, correct?
 
Back
Top Bottom