Sandbox refresh creating inaccessible scheduled batch job

Question

I have a batch job that reschedules itself on completion so that it can essentially run indefinitely. Within its finish method it calls system.scheduleBatch to start itself again after a defined interval.

This works well, and is backed up by a Schedulable implementation that periodically checks both CronJobDetail and AsyncApexJob to resurrect it if required.

The problem occurs after refreshing a sandbox from production where the recurring batch and scheduled job are running.

After refreshing a sandbox it was found that the batch job wasn't running. However, attempting to call system.scheduleBatch with the standard jobName gives an error that a job with the name is already scheduled.

XyzBatchOrderSynchronization batch = new XyzBatchOrderSynchronization();
string jobName = 'XYZ Batch Order Synchronization';
string jobId = system.scheduleBatch(batch, jobName, 3, 1);

System.AsyncException: The Apex job named "XYZ Batch Order Synchronization" is already scheduled for execution.

A query against CronJobDetail with the job name returns a result: (Job Type 7 is Scheduled Apex)

Select Id,Name,JobType from CronJobDetail where Name = 'XYZ Batch Order Synchronization'

However, a query against CronTrigger with that CronJobDetailId returns no results:

Select Id,CronJobDetailId from CronTrigger where CronJobDetailId = '08a5000000E07EzAAJ'

Without the CronTrigger Id I can't use System.abort(jobId) to clear the old job.

How can I clear out the rogue scheduled batch job that came via the sandbox refresh process?

The customer is raising a support case, but it seems odd that I can't get to it. I guess I could modify the code to make the job name unique/configurable, but it seems odd to leave the old scheduled batch lying around not running.

Answer 1

You can't fix this. If it happens, it happens, and you need to submit a case. Basically, one of the tables on the backend gets out of sync because the snapshot happened at just the wrong time. This results in a job with no detail record associated to it. As far as I know, the only way to fix this is to manipulate tables we don't have direct access to... so you need support. Last year I ended up having to submit about 4 or 5 such cases, because we'd spin up two sandboxes (dev, QA), and end up with one or the other stuck in limbo. Of course, there's ways around this, like using random job names, but you'll still be penalized against the system-wide limits for how many jobs you can have scheduled at once. About the only way you can almost certain it won't happen is to stop all scheduled jobs before attempting to copy your sandbox, and waiting until the copy completes. This is often impractical, so simply submitting the case is usually your best option.