4

Background

I have been working with Salesforce Support for several weeks now trying to get them to escalate an internal server error with GACK 2134764861-123797 (1611479512) (1611479512). After a long period of waiting I was told that in order to escalate quickly they needed to reproduce the issue in a controlled way. This was again taking them a considerable amount of time so I created a reduced test case myself (https://github.com/dsharrison/spring-17-ant-error-reproduction) that concisely reproduces the issue with a very small amount of code. I was told that this wasn't a valid reproduction because it caused a different GACK (1291518605-518052 (1659192199) (1659192199)) despite reproducing the exact same user experience.

My Question

What makes up a GACK? Is there any information that I can take from their structure that can give me clues on which errors are related without access to the full back-end tools that Salesforce Support uses? It is not infrequent that without premier support it takes me upwards of two weeks to escalate platform bugs and I am hoping that I can somehow use the information from the GACK to reduce this time.

Improve this question
1

1 Answer 1

Reset to default
4

The best publicly available information on the structure of a gack is this blog post from Josh Kaplan

Specifically,

These two numbers, respectively, are the identifying ID for that specific event, and the general stack trace that was produced by that failure.

Since the numbers are different (specifically the parenthesized number) that would mean that your repro is getting a different stack trace and "Id" for lack of a better term.

With that said, outside of matching either portion of the GACK they aren't useful to you. Think of them more as serial numbers for SFDC to use when looking at error logs.

On that note, if you're still able to reproduce the issue please add a comment on my answer and I'll see about finding you some help.

Improve this answer
3
  • Thanks for following up on this. With some sweat I was able to get this to Tier 3 support who quickly admitted that despite the stack traces being slightly different I had indeed identified and reproduced a platform regression bug and they provided a workaround in the form of a restructure to the SOQL query. I have not followed up on whether or not this has been fixed since the workaround was easy enough to implement.
    – dsharrison
    Jul 18, 2017 at 4:57
  • Thanks - is there any chance you can share the case number on that? If it's still happening I'm going to log a bug when I get a chance.
    – ca_peterson
    Jul 18, 2017 at 4:58
  • Yeah, I'll try to dig it up and post it back here if I can.
    – dsharrison
    Jul 18, 2017 at 5:19

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.