RemoteControl Exec fails for closures when used from jsm only instance to Jira and vice versa

[Srikanth Ganipisetty]

Let's say we have 2 instances:

Instance 1:  JSM(5.10.0) installed with no Jira software. 

Instance 2: Jira Software(9.5.1) with no JSM.

Both instances use the same JDK version(Tested on 11.0.19-tem, 11.0.20-tem). 

Create a 2-way application link between these instances.

In Instance 1, Navigate to the Scriptrunners script console and run the following

import com.atlassian.applinks.api.ApplicationLink
import com.atlassian.applinks.api.application.jira.JiraApplicationType
import com.atlassian.applinks.api.ApplicationLinkService
import com.atlassian.jira.component.ComponentAccessor
import com.onresolve.scriptrunner.remote.RemoteControl
import com.atlassian.jira.component.ComponentAccessor

// Replace url with your target remote Jira instance url
def REMOTE_JIRA_URL = "http://localhost:8080/jira"
def jiraAppLinks = ComponentAccessor.getComponent(ApplicationLinkService).getApplicationLinks(JiraApplicationType) as List<ApplicationLink>
def targetRemoteJiraAppLink = jiraAppLinks.find { appLink -> appLink.displayUrl.toString() == REMOTE_JIRA_URL }

RemoteControl.forAppLink(targetRemoteJiraAppLink).exec {
    [1, 2].find { it == 1 }
}

The above fails with exception:

io.remotecontrol.client.RemoteException: An exception was raised in the remotecontrol application
	at io.remotecontrol.client.RemoteControlSupport.processResult(RemoteControlSupport.java:51)
	at io.remotecontrol.client.RemoteControlSupport.send(RemoteControlSupport.java:39)
	at io.remotecontrol.groovy.client.RemoteControl.exec(RemoteControl.java:41)
	at io.remotecontrol.groovy.client.RemoteControl.exec(RemoteControl.java:34)
	at Script3.run(Script3.groovy:16)
Caused by: java.lang.NoClassDefFoundError: Script3$_run_closure2$_closure3
	at Script3$_run_closure2.doCall(Script3.groovy:17)
Caused by: java.lang.ClassNotFoundException: Script3$_run_closure2$_closure3
	... 1 more

Try to run the same code by modifying the URL on instance 2, Fails with the same error.

Noticed that sometimes one of the instances may not throw this error.

Known workarounds: None at the moment

Not been able to reproduce using JDK 8 yet.