9

Once in awhile when I try to convert a lead, I get the following error:

Error: System.LimitException: Too many namespaces accessed: 10 External entry point

It happens pretty infrequently and I can't identify any commonalities with the records it happens to. I've run a debug log to try and identify the problem and it's occurring once it enters a managed package, but I'm not sure what inside the package is causing the error. It enters a few packages prior to the last one without problem.

My questions are:

  1. Is there a way to see a debug log with the individual triggers/classes firing to narrow it down a bit more?

  2. Is there a way to see each namespace accessed within the debug log?

  3. Is there any other good way of resolving this problem?

Thanks in advance

1
  • For what it's worth I've heard stories that salesforce sometimes is willing to increase this limit with a good business justification. Nov 5, 2015 at 2:52

1 Answer 1

9

So, this is the Maximum number of unique namespaces referenced limit, which currently maxes out at 10.

The explanation from the linked documentation:

In a single transaction, you can only reference 10 unique namespaces. For example, suppose you have an object that executes a class in a managed package when the object is updated. Then that class updates a second object, which in turn executes a different class in a different package. Even though the second package wasn’t accessed directly by the first, because it occurs in the same transaction, it’s included in the number of namespaces being accessed in a single transaction.

So, probably based on the triggers firing and subsequent DML operations, the code is reaching more than 10 different namespaces.

In the debug logs the first thing I'd look for would be LIMIT_USAGE_FOR_NS events. There will be one of these for each namespace, with the namespace identified in the first data after the event. E.g.

19:01:46.137 (1137952897)|LIMIT_USAGE_FOR_NS|TheNamespaceHere|

The other useful events to look for will be:

  • CODE_UNIT_STARTED. These occur when the triggers start. Again, the namespace is included in the subsequent data.
  • ENTERING_MANAGED_PKG. Useful as it only requires the INFO log level. (Thanks for the comment Chris)

Resolving the problem will largely depend on how all the different packages are being reached. It may be necessary to make some of the processing asynchronous.


Try using something like the following from the Developer Console anonymous Apex to capture the debug log:

Lead testLead = [Select Id from Lead Limit 1];

Database.LeadConvert lc = new Database.LeadConvert();
lc.setLeadId(testLead.id);

LeadStatus convertStatus = [SELECT Id, MasterLabel FROM LeadStatus WHERE IsConverted=true LIMIT 1];
lc.setConvertedStatus(convertStatus.MasterLabel);

Database.LeadConvertResult lcr = Database.convertLead(lc);
System.assert(lcr.isSuccess());

System.assert(false, 'rollback transaction');
10
  • I don't see either of those events in my logs. I've run the debug on FINE and FINEST -- are these the wrong levels to run the log at?
    – Matt
    Nov 4, 2015 at 20:30
  • LIMIT_USAGE_FOR_NS "should" appear with the FINEST level on ApexProfiling. CODE_UNIT_STARTED should appear with ERROR on ApexCode. All other levels can be ERROR or NONE. Salesforce did fiddle with the logging levels a bit in Winter '16. Let me check. Nov 4, 2015 at 20:36
  • I see LIMIT_USAGE_FOR_NS listed under ApexProfiling at the FINEST level, but I don't see CODE_UNIT_STARTED on any level for Apex Code. I double-checked and ran another log and still don't see either within the log. I'm running the debug on sandbox, would that affect it at all?
    – Matt
    Nov 4, 2015 at 21:19
  • 1
    Looking for ENTERING_MANAGED_PKG might be good, since it shows at INFO rather than FINEST it's less likely to get truncated. Nov 5, 2015 at 2:51
  • 1
    I'm running into the same problem. It seems to me that the conversion process should have a higher limit since there is a high likelihood that managed packages will have triggers on one of the many standard objects that can be involved in the conversion process, and in many cases removing managed packages won't be a viable solution. If you agree please vote for my idea success.salesforce.com/ideaView?id=08730000000cJH3AAM. Feb 16, 2016 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.