Governor Limit Gotchas Part 1 - The Future Call

When doing development in a multi-tenant environment, there have to be certain limits in place that keep applications from running out of control and causing performance problems for other users of the environment. These limits are often referred to as governor limits, and while I agree with putting them in place to control applications, I often find they can be hard to work with. This is part one in what will no doubt be a multi-part series of blogs around some of the gotchas I run across when developing in the cloud.

For this entry in the series, I am going to focus on the Force.com platform and one of its governor limits relating to future methods. Future methods are a great tool to help alleviate a lot of the other governor limits that the Force.com platform imposes on us. Future methods are used to send processing out to a queue that will be executed when resources are available. Because of this, the governor limits are looser on these methods. That’s not to say that these are a fix-all to avoid governor limits in your applications. They still have limits around things like querying, DML, script statements, etc., they just tend to be higher than in standard triggers. They also have a couple special limits that affect only future calls. These two limits are: you can make no more than 10 future calls in a transaction; and you can have no more than 200 future calls per license, per 24 hour period.

I have been working on an application enhancement for one of our clients for awhile and the application was deployed to the production organization last night. Everything went well, and the application seemed to be performing properly. After verifying the code was working properly, I had to update almost 2 million records. We had done this before, a few times, in the client’s sandbox, and had experienced no problems. However, after letting the update run through the night, we discovered we had hit the 200 future calls per license per 24 hour period rule, and the updates had begun to fail because of this. While this posed a minor problem, we couldn’t get the records updated right away, the fallout problem was much worse. I use future calls in various places throughout the organization for tasks that users perform on a daily basis. Now, since the limit had been reached, all the users were experiencing problems performing their daily activities. Every time they saved a record that called a trigger with a future call, the save would fail. By the time we were able to work with Salesforce to get the limit raised temporarily, the day was almost over.

There were two main issues that caused this problem for us. The first was that I didn’t fully understand the governor limit at hand. I figured that because I ran most of the updates at night, that they would recycle for the morning and it wouldn’t affect anything. As it turns out, I was wrong. The limits recycle on a 24-hour basis, which means they go away 24 hours after they are created. For example, if I ran updates that called 10,000 future calls at 8:00pm, 10,000 future calls at 9:00pm, and 10,000 future calls at 10:00pm, I would have locked up 30,000 of my organization’s available future calls until 8:00pm the next day, 20,000 until 9:00pm the next day, and 10,000 until 10:00pm the next day. In other words, there is no daily turn over, it’s a true 24 hours from when the call was made, that it will be freed up again.

The second problem at hand here, was that for this particular limit, the sandbox has a much higher threshold than production. As I said before, we had run these updates multiple times in the sandbox with no problems at all, so I was surprised to see the issue come up in production. After talking to developer support at Salesforce, I was informed the limit is much higher in the sandbox to allow for thorough testing of your application. This, to me, is backwards. How can I thoroughly test my application, when it is not bound by the same rules in the testing area as it is in production? When I ran the updates in the sandbox, I was specifically looking for these types of issues to come up. Since they did not, I figured we were fine to move to production.

So, what’s the solution? The truth is, I don’t have a great solution, yet. Salesforce does not provide us with a way to monitor our daily future calls, so until we hit the limit, we cannot tell how close we are getting. Going forward, I will definitely be more mindful when running large updates to a production organization. While doing this will hopefully help our clients to not have to deal with this issue again, I feel there are a couple things Salesforce can do to help the developers be more cognizant of this issue. The first way of helping would be to give us a way to monitor how many daily calls we have made. It could be a report, an Apex method, or an entry in the monitoring section, just something so we can see our usage and adjust our code, or behavior accordingly. The second thing to help would be to make the limits in the sandbox match the limits in production. Normally I would never ask for stricter governor limits, but I do not feel I can adequately test code that may encroach on the limits in production, if the limits do not exist in the sandbox I am developing in.

For more details on Force.com’s governor limits, check out their documentation here. Stay tuned for more entries into this series, as I’m sure I will run into new and interesting issues as we go further and further into cloud development.