10

I spent quite some time debugging an issue because the stack trace line numbers were not correct and wanted to share my findings. The problem seems to be 10 Years old and fixed, but under specific circumstances, it seems to be still a problem.

I am able to reproduce it, but I'm not able to reproduce it with custom code only.

Run this in anonymous apex:

System.debug(1);

if(Trigger.isBefore) {
    System.debug(2);
}

It will fail in line 1. (The latest thing that happens before line 3, where the Exception originates from). I totally get why it is thrown (the flag is null), but to find out that this was the issue took me hours if not a day because I spent all the time debugging line 1 instead of 3. Frustrating. I am not able to reproduce this by creating my own nullish flags as it was done in the 10 years old post. if(nullFlag) leads to correct line numbers, only the Trigger.flags are leading to wrong stack trace line numbers (is the internal Trigger class running on a super old API version??).

Also Setting the logging Level to FINEST does not solve it (as it solved it back then).

Should I create a case, or is this just a thing that will never be fixed? does anyone have any insights about the fixing progress of the old issue?

UPDATE

I created a case and the SF support is working on it. I asked for any public reference, but there is none. I will try to test it once in a while and keep you updated. Their statement:

We assure you that issue will be resolved and we currently linked the BUG to this case number with high priority as reference.

Currently, as per salesforce policies the Known Issue article will not be created on a Single Incident as further more customers reach to us raising the incident the Known Issue will be created on approval of the higher team to track it further.

Improve this question
5
  • 3
    That is why before checking any trigger context variable check Trigger.isExecuting only then use Trigger context variables.
    – Nagendra Singh
    Commented Jan 18, 2022 at 13:33
  • 2
    I've never trusted them in Anon Apex, TBH. However, someone armed with the above knowledge can successfully navigate the misdirection minefield and discover the true source of the problem. BTW, for me it is stupid that null cannot be treated as false in such a Boolean check scenario. This would, for me, be a more helpful fix.
    – Phil W
    Commented Jan 18, 2022 at 13:52
  • I suspect it has to do with some null checks being performed before updating the row/line counters, perhaps a "fail-fast" implementation. Still, I agree it should be considered a logic bug. It probably won't do any good, but I'd log a bug regarding this. Until then, the workaround, as Nagendra said, is to check Trigger.isExecuting if your code doesn't know for sure if it's in a trigger context.
    – sfdcfox ♦
    Commented Jan 18, 2022 at 13:54
  • 2
    FWIW, I've put out a message on Twitter. We might be able to get more insight into the problem.
    – sfdcfox ♦
    Commented Jan 18, 2022 at 14:04
  • I fully agree with you @PhilW, it's sad, that it's working this way, I got used to it, but somehow I would have never expected apex to provide wrong line numbers and did not expect the Trigger class to be fragile, turned out I was wrong :/ Great, thank you @sfdcfox!
    – itsmebasti
    Commented Jan 18, 2022 at 15:17

1 Answer 1

Reset to default
8

As you have demonstrated, this is a bug.

The resulting System.NullPointerException should have a line number reference back to the is statement line on line 3.

Please raise this as a support case and let me know the resulting case number. You can reference W-10450606 in the support case as well as the internal reference that we will use to resolve it.

Improve this answer
1
  • 1
    Thank you, done! In case it helps anyone, this is the Case Id: #41943112
    – itsmebasti
    Commented Jan 18, 2022 at 18:04

You must log in to answer this question.

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