8

I have a System.Queuable job, on a particular Sandbox that is giving me issues. It works fine on other Orgs, but fails on this particular one.

The job structure is this:

  • Batch Apex job calls System.enqueueJob (batch size of 1)
  • System.Queueable execute method calls System.enqueueJob again, to a level of 4 deep (which makes 5 including the one in Batch job)

This essentially yields the following stack of jobs:

  • Parent (enqueued in Batch Apex)
    • Child
      • Grandchild
        • Great Grandchild
          • Great Great Grandchild

As I said, this works fine on a DE org, but when I enqueueing the Child job on Sandbox, it fails with:

System.AsyncException: Maximum callout depth has been reached.

The documentation states:

Queueable Apex Limits

  • The execution of a queued job counts once against the shared limit for asynchronous Apex method executions.
  • You can add up to 50 jobs to the queue with System.enqueueJob in a single transaction.
  • No limit is enforced on the depth of chained jobs, which means that you can chain one job to another job and repeat this process with each new child job to link it to a new child job. For Developer Edition and Trial organizations, the maximum stack depth for chained jobs is 5, which means that you can chain jobs four times and the maximum number of jobs in the chain is 5, including the initial parent queueable job.
  • When chaining jobs, you can add only one job from an executing job with System.enqueueJob, which means that only one child job can exist for each parent queueable job. Starting multiple child jobs from the same queueable job isn’t supported.

I believe I am reading the 3rd point correctly, and I should not be experiencing this issue. Anyone any thoughts?

(additionally, this sandbox is not producing any logs)

Improve this question
3
  • Is it recursive, or five separate jobs? Maybe it's trying to enqueue a sixth when you think it's not supposed to?
    – Adrian Larson ♦
    Aug 12, 2016 at 14:27
  • The 3rd point applies to a DE Org, not a Sandbox. You shouldn't see that limit at all in a Sandbox tied to a production org! Logging my not be enabled for the user context you have the job running under. It's disabled by default in a new sandbox for users.
    – crmprogdev
    Aug 12, 2016 at 14:59
  • It's recursive, but code in place to prevent it going deeper than 4 in the recursion (i.e. batch + 4 = 5). So, it did work in the Sandbox, came along a couple of days later and it stopped working. It fails to enqueue the Child job which is the second in the chain (i.e. the first in the recursion). I know the 3rd point relates to DE orgs, but i should be better off not worse in Sandbox.
    – Phil Hawthorn
    Aug 12, 2016 at 15:17

2 Answers 2

Reset to default
10

There is an Idea out there called Allow callouts from chained queueable Apex jobs. Here's the description, with some minor reformatting:

Allow callouts from chained queueable Apex jobs

Currently (Spring '15 release) callouts are not allowed from chained queueable jobs. The intial queable job will perform the web callout but any subsequent jobs that are chained from the first job will fail with the "System.AsyncException: Maximum callout depth has been reached." This severly limits the usefulness of chaining queueable Apex jobs for our use case for running asynchronous Apex code.

See the following links:

Update

As of Spring '17, you can Make Web Service Callouts from Chained Queueable Jobs:

Apex now allows web service callouts from chained queueable jobs. Previously, a queueable job could make a web service callout, but additional chained jobs that made callouts would throw exceptions.

Improve this answer
3

So, I figured out the issue. The Queueable class had Database.AllowCallouts set in one org, but not the other. I'm not sure why that has an impact, but removing it clears the issue.

Improve this answer
3
  • appleman addresses the callout issue in queueables in Advanced Apex 3rd Edition Chapter 7 pg 175-6 by catching the exception and then retrying using a future method
    – cropredy
    Aug 12, 2016 at 17:44
  • 1
    @cropredy Should it be caught though? Developers should know that it's going to fail, why not just call into the future method when you want to en-queue a second job
    – EricSSH
    Aug 12, 2016 at 19:01
  • 2
    @EricSSH - Appleman pattern is centralized/generalized async event handler where some events may need to do callouts and some may not - hence the try-catch-retry logic. If not using such a centralized async handler, then I agree with your remark
    – cropredy
    Aug 12, 2016 at 19:13

You must log in to answer this question.

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