28

EXCEPTION: System.StringException: You can't abort scheduled apex jobs by calling system.abortjob with an AsyncApexJob ID. You must call system.abortjob with the parent CronTrigger ID. I tried same in workbench with lowed api version then it worked. I was able to delete 2 jobs in API version 32. Follow these steps to run this statement: login to "https://...


19

When you say "schedule a task", I'm going to assume you're talking about a batch class that performs work. If that's the case, I believe your issue is related to how asynchronous processing works on the platform overall when you have to share resources with other orgs on the same pod. During times of heavy load, when thresholds are exceeded for server ...


13

You might be able to accomplish this by executing the query given with an additional LIMIT 0 at the end. You'll still use one SOQL query, but I don't believe this will count against the total number of rows retrieved. Something like: string userQuery = 'select ID from Contact where Name like \'myContact%\''; try { Database.Query(userQuery + ' LIMIT 0')...


10

In case Phil's solution doesn't work, and you are stuck with a zombie Queued AsyncApexJob, here's a workaround: At Version 39.0, an attempt to delete a zombie Queued AsyncApexJob that has no associated CronTrigger using System.abortJob(theAsyncApexJobId) fails with: System.StringException: You can’t abort scheduled Apex jobs by calling System....


7

If it's queued that implies its scheduled, therefore you should be able to get the Job ID and abort it, e.g. System.abortJob(jobId);


7

You should be able to get the class name by doing this: Select Status, ApexClassId, ApexClass.Name From AsyncApexJob


7

This is one of those situations where you have to cheat to get perfect coverage. What you need to do is call your queueable's execute method without actually using the queueing mechanism-- then, the recursive call will fire appropriately, allowing you to get that perfect coverage. Something like this: // Do whatever initialization you need. Test.startTest()...


6

It's a rolling window. The start of the range is the same as what you would get from Datetime.now().addHours(-24).


6

CronTrigger is the parent job that will be run; it can have many runs attached to it. AsyncApexJob is a single job, including batchable, queueable, and future methods. So, if you want to know what's coming up, CronTrigger will let you know what's scheduled, while AsyncApexJob shows prior executions. If you want to know what's already run, AsyncApexJob is the ...


6

Setup | Deployment Settings | Allow deployments of components when corresponding Apex jobs are pending or in progress. Caution: Enabling this option may cause Apex jobs to fail. The above applies to deploying into a target org If you are developing in a sandbox, and you are editing an apex class that is used in a running job of that sandbox, you need to ...


5

See What are the differences between the different possible jobs processed in the 'AsyncApexJob' object? for more information on jobs, but specifically they cover ApexToken: An 'ApexToken' job is used for Flex Queue enabled organizations. From Winter '16 onwards, the flex queue is enabled by default for all organizations. If an Apex code block invokes ...


5

So, all my experimentation has come down to this: it appears that the standard interface is technically lying to you; the finish method runs at its leisure sometime after the Completed status occurs and the CompletedDate field is populated. If you want the true completed status, you'll have to come up with an arrangement beforehand, something that your batch ...


5

We ran into this issue with Summer 16 and have opened a ticket with Salesforce. They acknowledge the issue is happening due to release and their R&D team is working on it. I'm going to ask whether my sandbox can be rolled back until they fix it, which will hopefully be soon. No idea whether they can do that, though.


5

It sounds like there was a discussion with someone in Salesforce that the Bulk API wasn't the right tool for monitoring deleted records. There is always the Data Export functionality. It's kind of async, but unfortunately doesn't have an API. Other than the REST API there is also the SOAP API, which is synchronous. See queryAll()


5

This is broad questions but let me try to give you summery 1) You can pass Array of objects to Queueable in future you can not. 2) You can chain jobs in Queueable in future you can not. Ex. You are calling API X and on success you are calling API Y with result of first call(X) this you can do easily in Queueable 3) Queueable is seen as combination ...


5

Turns out that I had to open a case with Salesforce to solve this. After more than 10 days, and two escalations, they didn't solve the issue. Since I didn't want to waste more time waiting for a miracle, I suggested the exclusion of the entire development environment (the sandbox) and creation of a new one. This solved the problem, with the downside of ...


5

Batchable, future, and queueable were basically three versions of the same feature request from customers. Initially, customers wanted a way to process bulk data asynchronously. We were given Batchable. Customers then complained that while batchable was great for mass processing, it was too "bulky" when all you wanted was simple asynchronous method calls, so ...


4

You may have to contact Salesforce support to fix this. They may be able to kill that queued job. We've had a similar issue in the past and we could only solve it by contacting SF.


4

This will actually a bug in the code. I can see this line - System.enqueueJob(new SecondQueueableApex(counter)); I assume this is calling itself, due to which it starts getting into stack. This will not be limitation of Queueable interface, but more about the how it is being called. Current limit for number of such chained jobs can be 5. Check "...


4

This code compiles indicating Database.BatchableContext is an interface: public class MockBatchableContext implements Database.BatchableContext { private Id jobId; private Id childJobId; public MockBatchableContext(Id jobId, Id childJobId) { this.jobId = jobId; this.childJobId = childJobId; } public Id getJobId() { ...


4

You can easily access this info using SOQL. There is an object called AsyncApexJob that contains information about Apex jobs. It will hold several types of jobs (like unit tests, scheduled jobs, etc.). It has a CreatedDate timestamp which you can use to find out when your job was submitted. select ApexClass.name, CreatedDate, JobType, LastProcessed, ...


4

From the ApexTestRunResult docs: MethodsCompleted The total number of methods completed during the test run. This value is updated after each class is run. I'm seeing this discrepancy as well when I look back through previous ApexTestRunResult records. In my cases I had parallel testing enabled. I'm assuming there is a race condition around multiple ...


4

The possibility of data going stale is not why future methods do not accept sObject parameters. Id values are future-compatible primitives and can also be stale, if, for example, the record is deleted prior to executing the future method. All asynchronous code must be concerned about the validity of the data it is passed relative to the current state of the ...


4

Personally, I've never used that parameter. But it is described in BatchableContext Interface as: BatchableContext InterfaceRepresents the parameter type of a batch job method and contains the batch job ID. Useful I guess if you want to manipulate the job that runs the batchable e.g. to abort it via System.abortJob.


3

You can easily get the details in apex Integer enqueuedJobs = [SELECT COUNT() FROM AsyncApexJob WHERE JobType='BatchApex' AND Status IN ('Processing','Preparing','Queued')] ; You can handle this in your code //check if there are 5 active batch jobs //In some cases, might need to add "Status='Queued' " to the criteria if ([SELECT count() FROM AsyncApexJob ...


3

This sort of situation is exactly what the FOR UPDATE clause is for: Locking Statements In Apex, you can use FOR UPDATE to lock sObject records while they’re being updated in order to prevent race conditions and other thread safety problems. While an sObject record is locked, no other client or user is allowed to make updates either through code or ...


3

I just tested this, and it's available immediately in the same transaction, before the current transaction completes. Obviously, this Id won't be available to other transactions before "final commit," but by the time T2 runs, it is guaranteed to have access to that record. futureimm.exec(); asyncapexjob j = [select id from asyncapexjob order by createddate ...


3

They are guaranteed to run sequentially. This is mentioned in the Execution Governors and Limits documentation: Maximum number of batch Apex job start method concurrent executions4 1 ... 4Batch jobs that haven’t started yet remain in the queue until they’re started. If more than one job is running, this limit doesn’t cause any batch job to fail and ...


3

Since the <apex:actionPoller> is just a glorified AJAX-Wrapper, each request is a new transaction with new limits. Quoting the documentation: Consider carefully the effect of your action method being called repeatedly by an at the interval you specify, especially if it's used on a page that will be widely distributed, or left open for long periods. ...


3

Calling Test.stopTest() only forces any asynchronous processing which is already enqueued to fire. It does not affect any subsequent asynchronous processing kicked off by those jobs. |-------------|------------|-----------> startTest enqueueJob stopTest job runs synchronously future invoked ...


Only top voted, non community-wiki answers of a minimum length are eligible