As designed Cron task run frequencies reset on each upgrade

[PaulB]

Affected version

1.5.21

Exactly what the title says. Each time an update is performed, all the cron task run frequencies reset to default.

 

[Martok]

This is not a bug and is confirmed here:

https://xenforo.com/community/threads/make-cron-entry-scheduling-editable.145183/#post-1238776

 

[PaulB]

@Martok It's definitely a bug. Just because it's confirmed doesn't mean it's not a bug. It makes absolutely no sense for it to work the way it does. That makes it a bug.

 

[Ozzy47]

It's not a bug, it is as designed. It may be changed in the future if the suggestion gets enough traction though.

 

[Martok]

@Martok It's definitely a bug. Just because it's confirmed doesn't mean it's not a bug. It makes absolutely no sense for it to work the way it does. That makes it a bug.

No, it's not a bug, it is as designed as you will see from other responses from the XF team:

You shouldn't directly customize crons associated with a particular add-on (in this case, "XenForo" is an add-on). It's worth considering creating your own cron entries with the changes you need.

You can edit the settings by clicking on the cron task.

You will have to edit them again after each upgrade though, as they will be reset.

There was even a suggestion to change this behaviour made in 2013 though that wasn't implemented due to a lack of interest.

https://xenforo.com/community/threads/keep-cron-modifications-during-an-upgrade.56238/

You should like the new suggestion I linked to in my first post if you would like the behaviour to be changed.

 

[PaulB]

@Martok Just because it's designed that way doesn't mean it's not a bug. For example, Zip Slip was an intentional design decision of the ZIP specification. ImageTragick was the result of a feature in ImageMagick. Both were deemed bugs by the broader community, which takes precedence over the decisions of the developers.

In fact, from reading what you quoted, it sounds like they're well aware it doesn't function optimally. They've chosen to deprecate an infrequently used, incomplete feature rather than fix it, which would require implementation of a versioning system. They're free to make that decision, but that doesn't change the fact that it's a bug. Now unless you have something constructive to add, such as a patch, please go troll elsewhere.

Here's a legitimate use case for changing cron entry run frequencies. userGroupPromotions doesn't run often enough by default. We have members who make purchases or cancel subscriptions and complain that the changes don't take effect immediately. At least if we set it to once per minute, we minimize those complaints.

... there’s very clearly an impression that those changes stick, when they won’t.

Sounds like acknowledgment of a bug to me.

 

[Martok]

Now unless you have something constructive to add, such as a patch, please go troll elsewhere.

I'm not trolling, I'm simply stating that it isn't deemed as a bug by the developers, they haven't seen it as one and haven't changed the behaviour despite it being like this since 2010 and the lack of interest previously from the community in changing this. I also helpfully linked to the current suggestion for changing this behaviour so you can like it and show your support for it (and with enough support the developers might then change this, that's how suggestions work). Please don't get arsey with me just because you don't like the answer that was given (which was also given by @ozzy47 too).

 

[PaulB]

I'm not trolling, I'm simply stating that it isn't deemed as a bug by the developers, they haven't seen it as one and haven't changed the behaviour despite it being like this since 2010 and the lack of interest previously from the community in changing this. I also helpfully linked to the current suggestion for changing this behaviour so you can like it and show your support for it (and with enough support the developers might then change this, that's how suggestions work). Please don't get arsey with me just because you don't like the answer that was given (which was also given by @ozzy47 too).

I appreciate the link, but I'm reporting this as a bug, not asking for help. I'm looking for a comment from the developers along the lines of "Won't Fix" or "Here's a patch". This saves me a significant amount of time, because then I either know for certain it's not going to be patched ever in 1.x (which means I need to patch it myself for our specific use case), or it's going to be patched in the future, in which case patching it myself would be a waste of time. I appreciate that you're trying to help, but I'm looking for a definitive answer from the developers for planning purposes. Yes, I believe I already know the answer, but I need to make sure before working on it.

(Sorry, accusing you of trolling was a bit rude on my part. I'm a bit frustrated.)

 

[PaulB]

Just to give a bit more context so it's clear I'm not trying to be a wise-ass here in asking for an answer directly from the developers: we maintain a bunch of patches that have to be applied to XenForo each time we update. This is pretty cumbersome, though for small updates, it's mostly automated. It saves us a lot of time if patches get implemented upstream. Some of these will never be submitted as bug reports because they're too specific to our use case (e.g., the need for read replicas and special image proxy handling). Others have been submitted as bug reports or requests, but we know for certain they're not going to be addressed in XenForo 1.x. Here's what that set of patches looks like:



Those patches only contain changes that couldn't be handled by an add-on, typically because the classes involved don't use the dynamic instantiator. Every patch that we're able to eliminate from that list saves us time.

 

[Chris D]

While it is certainly possible to deliberately write code which opens up major vulnerabilities, the intended outcome of these features certainly was not to allow arbitrary remote code execution. So as much as those features were as designed, I'm certain the side effects they caused were not intended.

Though, why are we comparing our inability to maintain certain changes in cron entries to features that resulted in nasty remote code execution vulnerabilities in other software? Slightly different ball park.

The key difference is the feature and the side effect, whether you agree or not, is working as we intended it to. Therefore it is not a bug, and it is as designed.

The recommended workaround is simple; disable the default entry and create your own Cron entry definition with the same values, adjusting the run times as needed.

 

[PaulB]

@Chris D Will the change persist? That is, will it remain disabled? If so, that's a perfectly acceptable workaround. It wasn't clear from reading the other thread whether that was the case.

 

[Chris D]

Yes, the active state for cron entries is maintained across upgrades (in both XF1 and XF2).