gabriel-farache commented on code in PR #4094:
URL:
https://github.com/apache/incubator-kie-kogito-runtimes/pull/4094#discussion_r2585940026
##########
jbpm/jbpm-flow/src/main/java/org/kie/kogito/process/impl/AbstractProcessInstance.java:
##########
@@ -225,9 +226,35 @@ protected void reconnect() {
}
getProcessRuntime().getProcessInstanceManager().setLock(((MutableProcessInstances<T>)
process.instances()).lock());
processInstance.setMetaData(KOGITO_PROCESS_INSTANCE, this);
+
+ restoreProcessInstanceContext();
+
processInstance.reconnect();
}
+ private void restoreProcessInstanceContext() {
+ Map<String, List<String>> headers = processInstance.getHeaders();
+ if (headers != null && !headers.isEmpty()) {
+ Map<String, String> contextMap =
convertHeadersToContextMap(headers);
+ if (!contextMap.isEmpty()) {
+
org.kie.kogito.services.context.ProcessInstanceContext.setContextFromAsync(contextMap);
Review Comment:
> considering that the invocation to the restoreProcessInstanceContext()
was produced by a caller thread, that is not under our control, aren't where
here making the caller thread to loose any potential values stored by him in
the MDC?
Does it make sense?
Yes it makes sense, a thread called the reconnect method but it does not
matter because the reconnect method is called by
`ContextAwareProcessInstanceLockStrategy` which clears the MDC context in the
end anyway.
Here restoreProcessInstanceContext() isabout restoring additional context
beyond just the process instance ID and this additional context is in the
headers
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
