0

Usually I ask questions about why something is broken in Salesforce, however, today I want to ask a different question.

We know that we can't deploy unpackaged code which introduces changes into Scheduled Jobs which are scheduled or any classes that such schedulable jobs depend upon.

This schedulable class has jobs pending or in progress

There is such settings to bypass this error by allowing deployments with Apex jobs in the Deployment Settings page in Setup.

Deployment Options

Allow deployments of components when corresponding Apex jobs are pending or in progress. Caution: Enabling this option may cause Apex jobs to fail.

Why such error doesn't happen if we package a scheduled job into a package and upgrade a package?

Package upgrade is deployment and if we introduce changes into Scheduled Jobs, which are scheduled, something can be broken.

Why then no error happens is we upgrade a package with changes into packaged schedulable jobs which are scheduled?

Improve this question
2
  • 1
    I would suggest the reason this is not deemed a problem is that during package upgrade the scheduled jobs are not executing. There's clearly some clever stuff going on under the cover since you can do an upgrade of a package on an org without down time. I'm guessing the upgrade is processed into a temporary clone of the environment, that shares the same DB layer, and only once completed successfully is the environment switched over. And this switch over is done such that there are no scheduled processes on-going at the time. (This is all supposition.)
    – Phil W
    Mar 31 at 15:49
  • I think you hypothesis is valuable, I should include that into the answer
    – Patlatus
    Apr 1 at 11:41

1 Answer 1

Reset to default
2

Looks like there existed some issue which was reported by some customers here for 1GP

The last time I tried to do a push upgrade of a managed package installation it would fail if the package was scheduled -- which is why I'm searching the SF forums now, to see if there is a solution.

So (if I'm understanding your post correctly) I should be able to do a push upgrade on a managed package even if it's scheduled? If that's the case, then what am I doing wrong?

However, looks like for 2GMP this was fixed or never was an issue.

By Phil W suggestion/hypothesis mentioned in the comment,

during package upgrade the scheduled jobs are not executing. There's clearly some clever stuff going on under the cover since you can do an upgrade of a package on an org without down time. I'm guessing the upgrade is processed into a temporary clone of the environment, that shares the same DB layer, and only once completed successfully is the environment switched over. And this switch over is done such that there are no scheduled processes on-going at the time.

Still, as sfdcfox mentioned,

in Spring 22, there was an error

when Scheduled Jobs were created via managed package post-install script having a Delete DML operation.

Improve this answer
2
  • 1
    I agree, it's not well-documented, far as I can tell, but I do remember that 1GP was very temperamental back in the early 2010s, but I'm pretty sure they've ironed out most of those bugs. Even so, as late as Spring 22, there was an error with some kinds of scheduled jobs.
    – sfdcfox
    Apr 1 at 2:15
  • @sfdcfox thanks for the link
    – Patlatus
    Apr 1 at 11:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .