IC Doesn't recognise System.Runas

[Justin Julicher]

Soon as I move it back it works.

‌

[Justin Julicher]

Actually it’s going green then when I move the cursor it goes grey again… hmmm

[Scott Wells]

Justin, I'm unable to reproduce this behavior. I created as simple System.runAs statement and moved the opening brace back and forth between end-of-line and next line and I never saw a syntax error. My sample looks like:

User user = null;
System.runAs(user)
{
    System.debug('Foo');
}

Does that reproduce the behavior for you?

[Justin Julicher]

Ok - once again a full rebuild of the OST fixed the issue.

‌

I was getting this error in the log:

‌

com.intellij.psi.PsiInvalidElementAccessException: Element: class com.illuminatedcloud.intellij.filetype.ApexClassFile #Apex  because: file:///home/justin/WebstormProjects/Cortex-GitFlow/classes/TriggerHandlerV2.cls is invalidinvalidated at: see attachment

It seems that if I delete a lot of files (the file above doesn’t exist) it causes unexpected results in the OST resolution.

Perhaps if you get an error like the above you capture it and remove that file from OST resolution and maybe log it in the event log or notify the user?

‌

thanks

‌

‌

[Scott Wells]

Thanks for the update. I'll investigate why these stale references are hanging around.

[Sander Elsen]

Hi

I had the same problem, full rebuild of the OST fixed it for me too.

[Justin Julicher]

What has happened now is that I’m getting an un-resolvable reference.

Any ideas?

Edit: Ok so I re-installed IC plugin then rebuilt OST. It seems to be recognising properly now as a proper System class has been created in the OST.

[Scott Wells]

For those of you experiencing this issue, can you please send me your idea.log while the problem is occurring? Also, do you see the following methods in the OST's System.System type?

    global static void runAs(SObject user, Object block)
    {
    }

    global static void runAs(Package.Version version)
    {
    }

I'm unable to reproduce this at all, but obviously multiple people are seeing it all of a sudden so there must be something going on...

[Justin Julicher]

Scott, it does seem sporadic in it’s nature.

I checked and my system does have:

global static ResetPasswordResult resetPasswordWithEmailTemplate(Id userId, Boolean sendUserEmail, String emailTemplateName)
{
}

global static void runAs(SObject user, Object block)
{
}

global static void runAs(Package.Version version)
{
}

global static String schedule(String jobName, String cronExp, Schedulable schedulable)
{
}

‌

This is what I got:

‌

And

I’ve also attached a my debug log.

‌

[Scott Wells]

Thanks, Justin. Unfortunately the log doesn't show anything useful. Is there perhaps some specific syntax that triggers this (relatively) reliably?

[Justin Julicher]

Not that I can figure out.

However, I did notice that when I go to the reference for runAs(User) it goes to the runAs(Package.Version) declaration.

Why would the Package.Version have a different signature to the user one? Wouldn’t you use it the same way?

‌

‌

[Scott Wells]

Funny...I see the same thing...well, the reference going to the wrong signature. I think it's because the User signature includes the extra (and incorrect) Object block parameter. I wonder if that is in fact related. I could (and probably should) fix that during OST generation. I'll do that and post a build here for you to try out to see if that makes a difference for you.

[Scott Wells]

Okay, here's a build that addresses the strange OST entry for System.runAs(User) and correctly adds references to the respective signature based on the call arguments.

After OST regeneration, the signatures should be:

    global static void runAs(User user)
    {
    }

    global static void runAs(Package.Version version)
    {
    }

Can you please install it, regenerate your OST, and see if it helps?

[Justin Julicher]

Ok thanks @Scott Wells

I’ve installed the custom IC build, rebuilt OST and will see if the issue happens again.

‌

thanks

[Justin Julicher]

Unfortunately this new build didn’t help.

[Scott Wells]

Well that's a bummer. I think at this point I'll have to ask if you can create a simple, standalone reproduction of the issue that you can send to me. I've tried to reproduce it quite a bit and always unsuccessfully, so hopefully given that it happens frequently for you, you can provide a way to reproduce it so that I can see/debug it.

[Scott Wells]

Delivered the fixes from the attached build in 2.0.9.7 but leaving this open since Justin is still seeing the core issue even with those fixes.

[Justin Julicher]

@Scott Wells

I think I’m going to resolve this one now. It’s stopped happening and I haven’t had a re-occurrence of it on the latest builds.

[Justin Julicher]

unable to reproduce now. latest builds seem to resolve the issue.

[Scott Wells]

Sounds good. Feel free to reopen if you see it recur and we'll try to get to the bottom of what's causing it.