In Salesforce, when a managed package class calls Exception.getStackTraceString() and the managed package is invoked synchronously from outside the package (for example, via Execute Anonymous), the full stack trace is visible because the invoking user's namespace context is blank (non-managed). However, when the same managed package class is scheduled as an asynchronous operation (for example, via System.enqueueJob()), the stack trace is hidden — only empty parentheses "()" appear in the error details. This difference in behavior is by design.
The scenario typically involves three Apex classes: a Thrower class in the managed package (which implements the Queueable interface) that catches exceptions and rethrows using getStackTraceString(), a ThrowerTest class in the managed package that enqueues the Thrower, and a ThrowerService class outside the managed package whose constructor throws an exception.
This behavior is working as designed. The key factor is the invoking user execution context at the time the transaction starts.
In synchronous execution, when an administrator runs code via Execute Anonymous, the invoking namespace is blank (non-managed). The namespace stack is: blank → MANAGED_NAMESPACE → blank. Because the exception is thrown within the blank namespace and the invoking context is also blank, the platform allows the stack trace to be logged and displayed to the user.
In asynchronous execution, the Queueable job is enqueued from within the managed package. When the async job starts executing as a new transaction, the invoking user context originates from within the managed namespace. The namespace stack is: MANAGED_NAMESPACE → blank. The platform protects the managed package's proprietary implementation by only exposing stack trace information within the managed namespace's umbrella — even if the exception was thrown in the blank namespace. This obfuscation prevents the managed package from exposing proprietary implementation details to subscribers.
000383964

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.