Set Queueable Stack Depth
One of the first rules you (should) learn about chaining queueable calls is to provide a mechanism to stop the chain if things go wrong. Queueable chains can execute very quickly if you didn’t specify a delay (which is the common use case) – so quickly, that it becomes impossible to manually abort the current job. And because you can’t overwrite metadata in an executing queueable, you can end up stuck – you may not be able to stop the endless chain until you use up your 24-hour async call limit.
One technique for preventing this is to use a counter variable in the queueable to keep track of the number of chains that have executed and to stop if you hit a specified maximum number.
The AsyncOptions features allows you to let Salesforce do the heavy lifting for you. You can specify the maximum number of chains, and if you try to enqueue a chained queueable that would exceed that number, Apex will throw an exception.
One caveat though – this only works if you are invoking the chained queueable from within the main execution of the queueable. If you attempt to chain through a transaction finalizer, it will only work on the first finalizer execution. When that finalizer enqueues the original queueable class again, the stack information will be cleared unless you create a new ApexOptions parameter (in which case you would set the max stack size to one less than it currently is).
This feature doesn’t really impact any of the design patterns in the book, as the approach there involves using a custom setting as a flag to shut off chaining that can continue as needed without limit.
Set’s are Iterable
And the crowd shouts Hallelujah! Set collections are now iterable (implement the Iterable interface), which means they can be used in places that previously required lists – such as the “String.join” function.
