+ Start a Discussion
Mediaroom EnterprisesMediaroom Enterprises 

Hitting CPU limits before it even gets to my managed package

Error: FATAL_ERROR|System.LimitException: Apex CPU time limit exceeded

The records basically come into my trigger code at Step 7 here (who knows if this is up to date):
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm

And the CPU limit shows it is over the limit as soon as it hits my package.
Maximum CPU time: 13170 out of 10000 ******* CLOSE TO LIMIT

At this point as an App Builder what the heck can I do? The user doesn't seem to understand I can't controll all the workflows they have setup. Of course the error email they get is right when it comes into my package and tries to run the first line so it looks like I'm the cause and Salesforce Support just tells them the same thing so it is futile to argue. Even running a limit check to see if the limits are blown throws the exception
 
Hargobind_SinghHargobind_Singh
Hi, 

If your package is managed, and is ALOHA status, can you check with salesforce support if the CPU time governor limit is separate from the unmanaged code in the org ? If so, then you would need to look into your package itself .. ? Just wondering... 

 
SFGSFG
It actually doesn't matter if you are an Aloha app. The CPU limit is accross all packages and code in the org as of WInter '14. 

http://advancedapex.com/2013/08/22/goodbye-script-limits/

"First, managed packages will no longer have their own set of script limits, or their own CPU time – CPU time will be shared among all managed packages interacting with a transaction and code native to the organization. As an ISV partner, this brings up an interesting question. What happens when some of that bad code, either on an org or in another package, uses up most of the CPU time, and when it becomes time for my package to run, limits are exceeded? Running a debug log with profile information should presumably allow identification of the greedy piece of code, but how many sys admins will take the time or trouble to actually figure this out? It’s so much easier to blame a package – possibly the one unfortunate enough to have tipped the CPU limit.  As this occurs more and more often, one can envision a case where customers gradually lose trust in applications in general, never knowing if one can be safely run. Ultimately this could impact trust in the platform overall. - See more at: http://advancedapex.com/blog/#sthash.l6oBCso8.dpuf" 
 
SFGSFG
Related Ticket (https://developer.salesforce.com/forums/#!/feedtype=SINGLE_QUESTION_DETAIL&dc=Apex_Code_Development&criteria=OPENQUESTIONS&id=906F0000000MKDNIA4" target="_blank)
I am finding in my testing that even though the documentation says Workflow is counted as part of the CPU limits - I am puzzled as to how that could be the case. I am seeing workflows run for 37 seconds then immediately go into a trigger and throw a CPU limit exception on the first line of the trigger which is 

  Integer LIMIT_MAX_CPU = 8000; //in theory this is 80% of what is allowed
 if(Limits.getCpuTime() >= LIMIT_MAX_CPU ) --> throws a CPU limit exception and it is the first line of the trigger.
kibitzerkibitzer
Here's what I do (as an AppBuilder) -
Capture a debug log. In the debug log there should be Limit sections that show the usage of each namespace.
Highlight the part that shows that your namespace isn't using any CPU time, then pass that back to the customer and Salesforce support.

Not to say "I told them so", but I saw this one coming 2 1/2 years ago: http://advancedapex.com/2013/08/22/goodbye-script-limits/
SFGSFG
Yeah, I see people putting some gnarly code in there and and as an AppBuilder, I'm the one whose name somehow shows up the logs for SF level 1 blames me and I spent days proving this is a problem elsewhere. Thx
kibitzerkibitzer
Right - the trick is to show that your name appears in the logs, and in the limits section is shows your app's name with zero CPU time. Which now becomes "proof" that it's not your app :-)
It is annoying though - maybe I'll propose it as a topic for a talk at next year's Dreamforce :-)