Deployment of class used in schedule job fails

[Oleksandr Tymchenko]

Hello,
During deployment of class used in scheduled batch class, deployment fails, however it’s allowed in
Deployment settings “Allow deployments of components when corresponding Apex jobs are pending or in progress.”

When we are doing pipeline deployment → it works
When deploying class via IC2 - fails

Another think -

private static Boolean checkSomething(CustomObject record) {
    return record.customField__c.equalsIgnoreCase('cats'); 
}

Method crying that ‘Missing return statement’ after replacing record.customField__c == 'cats' to equalsIgnoreCase

[Scott Wells]

Thanks for reporting. Something must have changed recently as previously only classes that implement Schedulable directly would fail when deploying via the Tooling API, and IC2 automatically looks for that situation and routes such deployments via the Metadata API. Now it seems that if something even peripherally related to Schedulable implementations is deployed via that API, it fails.

The workaround is to disable Tooling API-based deployment for Apex in Illuminated Cloud | Configuration Application | Validation and Deployment. I’ll investigate and try to figure out the pattern (if possible) and update IC2’s corner-case logic to handle it.

[Scott Wells]

Hi. I’m taking a look at both reported issues today and am unable to reproduce the second one where it’s reporting Missing return statement …, e.g.:

‌

Note that it’s effectively the exact same code but with no such error.

Are there any other errors in the same file, perhaps earlier? The parser should have robust recovery, but I’m wondering if there’s something else needs to be present to produce that false positive from the control flow analysis code inspection.

[Scott Wells]

Regarding the main issue here, it looks like the rules have changed a bit somewhat recently:

https://help.salesforce.com/s/articleView?id=000384960&type=1

Unless my understanding was incorrect, it used to be that only classes that directly implemented the Schedulable interface would fail during deployment when Deployment Settings | Allow deployments of components when corresponding Apex jobs are pending or in progress was not enabled and those classes were actively scheduled and deployment occurred via the Tooling API. Now it appears that deployments that include transitive dependencies of actively scheduled Schedulable implementations will also fail under those conditions.

IC2 can easily find transitive dependency/dependent relationships, so I’m going to see if there’s a good, efficient way to determine whether the requested deployment payload includes not only Schedulable implementations but also transitive dependencies of those implementations.

[Scott Wells]

I committed a fix for the main issue. IC2 now looks for the following when deploying:

1. Whether the project contains any Schedulable classes.
2. If so, whether the org has any active (queued, preparing, processing, or holding) Schedulable classes.
3. If so, whether the files requested for deployment include active Schedulable classes or their transitive dependencies.

If the last check evaluates to true, the deployment must occur via the Metadata API; otherwise is can occur via the Tooling API (if other unrelated checks also pass).

These changes will be included in the next official build.

[Oleksandr Tymchenko]

Hello,
Could you please tell me which logs I should send to you to review problem with the inspection?
I’s quite common that after one not fully correct statement, apex inspection fails and not recovering.Only deleting code part and inserting again helps to “recover” validator.

[Scott Wells]

You can send the idea.log file (Help | Show Log in Explorer/Finder/Files) from immediately after this happens. I wouldn’t expect that to be the case, so I’m curious as to whether there are any errors/exceptions in the log corresponding to it starting.

Can you also confirm that you’re on the latest builds of both IC2 and the JetBrains IDE and that it still happens on those versions?

[Oleksandr Tymchenko]

Yes, both latest.
I will send you when it happens again.

[Scott Wells]

Thank you. It would also be very useful if you could provide reliable steps to reproduce, potentially even in a standalone project that you could share where you could say:

1. Open the provided project.
2. Open FileXYX.
3. Make these changes to FileXYZ and you’ll see errors that don’t go away.

‌

‌

[Scott Wells]

Delivered in 2.3.2.0.