we think there could be interesting to investigate.

If you try to follow our test case :
 1. You start the main process : x.y.Z (the process is configured to be a PerProcessInstance)
 2. The first service activity that async calls an external web service fails, as ther is no web service reachable.
 3. The corresponding Work Item Handler starts an exception handler sub-process (handlingProcessId+ handlingStrategy)
 4. If you try to cancel th main process, then the following error raises : org.kie.internal.runtime.manager.context.ProcessInstanceIdContext@102de5b5: java.lang.IllegalStateException: Invalid session was used for this context org. kie.internal.runtime.manager.context.ProcessInstanceIdContext@102de5b5

Let's examine the org.jbpm.workflow.instance.node.WorkItemNodeInstance class in the jbpm-flow-7.39.0.Final-redhat-00007.jar (PAM 7.8.1)
 In WorkItemNodeInstance::cancel , one wants to abort the subprocess if it exists :
 exceptionHandlingProcessInstanceId > -1
 To identify it, a getKieruntimeForSubprocess() is called.
 (see attached screenshot n°1)

Let's look at the getKieRuntimeForSubprocess code (see attached screenshot n°2).
 At lines 671-672, a get of kruntime is made, but without giving some process information. So, the context is created wihout the process instance id.
 Thus, at lines 678-679, a new ksession is created but with a lacking context.

Back to the cancel method (see attached screenshot n°1), at line 393, a get of the instance of the exception handling process (line 393) is made. The code tries to validate that the ksession associated with the runtime corresponds to our process instance. It does not : the ksession is inevitably different from the one used to start the exception handling process instance as explained earlier.
 As a consequence, a "Invalid session was used for this context" error is raised. Always.

If one explicitly creates a context for the exception handling process instance with the following code, the problem disappears.
 if (exceptionHandlingProcessInstanceId > -1) {
 org.kie.api.runtime.manager.Context<?> context = ProcessInstanceIdContext.get(exceptionHandlingProcessInstanceId);

This is quite close to the issue https://access.redhat.com/solutions/1183403 but with a different cause.

Hope it can help