Checking for dependencies of active Schedulable classes during deployment can be slow in larger projects

[Sebastiaan Simons]

Hello Scott

I might have missed something in the release notes, but I’m getting this ‘dependency checker’ from time to time when I want to deploy. Can I disable this feature somewhere? I can’t seem to find it.

Thanks,

Seb

[Scott Wells]

Hi. This check is required when trying to deploy Apex via the Tooling API when there could be active Schedulable implementations to avoid an incorrect deployment failure that includes one of those implementations or a transitive dependency. It can only be disabled by disabling deployment of Apex via the Tooling API. Otherwise you would still be subject to the Tooling API deployment bug with active Schedulable implementations.

I'll keep this open to consider other potential ways to handle this specific situation, e.g., instead of checking for this state proactively, looking at deployment errors to see if the deployment failed due to an active Schedulable class or one of its dependencies and retrying the deployment via the Metadata API instead.

[Sebastiaan Simons]

Ok thanks!
The check takes quite some time, so it can be a bit annoying to wait for it.

[Scott Wells]

Totally understood. In most projects it should be close to instantaneous. Can you characterize this project in terms of the number of Schedulable implementations that are present locally and the total number of Apex classes in the project so I can better understand a project where this check takes significantly longer?

[Oleksandr Tymchenko]

Hello Scott,
Could you please disable this check if Tooling API for APEX is unselected?
If unselected, it will use metadata api and we are good anyway.

[Scott Wells]

Aha! It actually should be doing exactly that, but I just noticed that the logic in that check is associating two conditions improperly and not short-circuiting as intended. I’ve already fixed that for the next build. So sorry for the mistake!

[Scott Wells]

I’ve been thinking about this and would like some feedback from those of you experiencing this problem. Even with the fix to ensure that disabling this check when not deploying via the Tooling API, I’m still thinking perhaps other changes might be required to ensure that this is as “under the hood” as possible.

The reason that deployment via the Tooling API is enabled by default is that, in most cases, it should be materially faster than deployment of the same metadata via the Metadata API. Unfortunately deployment via the Tooling API has several bugs that don’t exist when deploying via the Metadata API including this one – not properly handling active Schedulable classes – and also several around deployment of individual LWC JavaScript files. So there’s a good reason for having deployments occur via the Tooling API as much as possible. However, since the goal of deployment via the Tooling API is that things happen more quickly, I want to make sure that any checks for known bugs – as in this case with active Scheulable classes – don’t result in Tooling API-based deployment being an actual impediment.

In this specific situation, IC2 tries to short-circuit the required checks as soon as possible (ignoring for a moment the bug when checking whether Tooling API-based deployment is enabled for Apex at all). It specifically checks the following:

1. Is Tooling API-based deployment enabled for Apex? This is the bug that I’ve fixed locally and will include in the next build.
2. If not, use the Metadata API; otherwise does the target Salesforce organization have any active Schedulable jobs?
3. If not, use the Tooling API; otherwise do the files requested for deployment include any of those active Schedulable jobs?
4. If so, use the Metadata API; otherwise are any of the Apex classes requested for deployment (transitive) dependencies of the org’s active Schedulable jobs?
5. If so, use the Metadata API; otherwise use the Tooling API.

It’s really step 4 is potentially costly here, and I’m trying to figure out if I can/should just avoid it. I can see three options for doing so:

1. If there are active Schedulable jobs in the org (the check from step 2), all deployments that include Apex must occur via the Metadata API. I don’t like this option because I imagine that it likely handicaps a large percentage of deployments unnecessarily to avoid a bug with a small percentage of deployments.
2. Just try deployment via the Tooling API without any of these checks and look for the specific error mesage that denotes that there are active scheduled jobs, then retry the deployment via the Metadata API automatically. This is actually similar to how IC2 works around known Tooling API bugs with LWC JavaScript deployments. This is what I’m currently considering, but I’ve also found that the specific error message can be a bit of a moving target, though it changes rarely.
3. Make this configurable by the end user. Generally this is the right approach, but in this specific situation, I don’t like it because it exposes the ugly details of these Tooling API bugs to the end user when most users really shouldn’t even know that they exist.

I’m leaning toward option 2 above even if it may require some minor touch-up over time if/when the error message pattern(s) change. In some ways this long post is bouncing the ideas above off of affected end users, so please feel free to let me know your thoughts, but mostly it’s just me capturing my own thoughts on better options for addressing it that balance the benefits of Tooling API-based deployment with avoiding the known issues with that deployment channel.

[Scott Wells]

Option 2 committed for inclusion in the next (i.e., tomorrow’s) build.

[Scott Wells]

Delivered in 2.3.2.3.