4

While Salesforce's internal processes are somewhat shrouded in mystery, we have been allowed a high-level look at the GACK process.

What our team is noticing is that certain GACK IDs are consistent : for example, we know that the code -547594032 is for the Document metadata type, and as far as we know is likely caused by hitting the limits of either deploying 10,000 files at once or having a zip larger than 39mb.

While we're not expecting an exhaustive list, is there a GACK ID to Metadata Type list for issues around the Metadata/Tooling/Bulk APIs available outside of the mothership?

2
  • I'd say there isn't. Amusingly ChatGPT suggested there was, twice, but in the end accepted there isn't one and you'd need to ask Salesforce for the meanings of individual gack codes. In the meantime try upvoting this idea.
    – Phil W
    May 5, 2023 at 9:27
  • Upvoted, thanks for the link
    – Rob Cowell
    May 5, 2023 at 9:56

2 Answers 2

10

I work for Salesforce on the Apex product team, but this is mostly personal opinion and not an official stance.

is there a GACK ID to Metadata Type list for issues around the Metadata/Tooling/Bulk APIs available outside of the mothership?

There is not, and I expect there will not ever be. A gack is by definition an unhandled exception in the Salesforce platform, and the message and quality of it, as well as any potential discussion of internals, is thus unpredictable.

The breakdown of a gack ID is semi-public, as Josh Kaplan said in the linked blog:

On gack notification such as these, you will see two numbers. The first of these numbers has a hyphen in it, and the second number is in parentheses.

I'll elaborate a bit more: the first number is a "serial number" of the gack that's going to be unique to a specific occurence. The same issue will have a different first number (let's call it a gack id).

The second number is a hash of the stacktrace (let's call it a stacktrace id) on the unhandled exception, which means that outside of the possibility of uncommon things like hash collisions the exact same gack should consistently have the same stacktrace id.

The stacktrace id doesn't tell you reliably what object/metadata it's related to, but for the same exception in the same call stack it's going to be identical.

There's some extra complexity to it, like in some cases the exception message isn't included in the hash, and in others it is, but in general the stacktrace id really just tells you if it's the same issue or not, and doesn't have any more meaningful data encoded into it.

A gack is by it's nature a bug. The priority and viability of fixing it are as always dramatically variable, but at a fundamental level "cleaning up" gacks to display would be basically the same as fixing them into proper externally facing error messages - except sanitized and public gacks have an extra layer of indirection and detective work.

8

The GACK ID values are derived heuristically, and are only meant for grouping crashes with the same root cause together, in order to define the frequency of the crash. It is up to a human to read the crash's logs to determine the severity and root source of the crash. The logs are expressed in terms of internal, intellectually-protected code, and so salesforce.com can't directly expose the source data, and the ID has no meaning until a human has read the logs to determine the root cause.

Once the crash's source is identified, it is logged manually into the internal bug tracking system that salesforce.com uses. These are the W-XXXXX numbers that you may be given. This bug tracker is also chock full of intellectual property, and so also can't be released to the public. However, salesforce.com is usually at least nice enough to provide the bug tracking ID so you can follow up with it later.

In addition, if a bug is severe enough, it will end up on the Known Issues page. You can see the "Reference ID" on each issue that's publicly available, and that's the closest you're going to get to knowing what that mysterious GACK ID is all about. This is the public information you're looking for. If you have a specific ID, you can kindly ask someone at salesforce.com to see if the ID has a Reference ID (a bug has been logged), which you can then check up on either with another employee with access, or on the KI page.

4
  • That certainly matches my own understanding, but my colleagues maintain there's a correlation between the error ID (the one outside brackets) and a specific metadata type, to the point there's a growing internal FAQ mapping them out
    – Rob Cowell
    May 5, 2023 at 9:51
  • 4
    @RobCowell That's because Salesforce's architecture is designed like an onion, with layers as you go deeper. Given a particular metadata type, it will typically crash at the same point in the same layer, even from multiple external configurations. However, it's not safe to assume that a given ID is the only one that corresponds to a given metadata type, just that the code is crashing in the exact same state through multiple sources.
    – sfdcfox
    May 5, 2023 at 9:58
  • 2
    +1 to everything sfdcfox said. As well it is not guaranteed that gack ids are stable across releases as the underlying implementation and stack traces may change.
    – David Reed
    May 5, 2023 at 17:25
  • 1
    And that relationship is definitely many-to-many in some cases. Gack A might in theory be triggered by deploying multiple metadata types. Metadata Type B might trigger many different gacks.
    – David Reed
    May 5, 2023 at 17:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .