New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: NPE fix when signal not found from model #3526
base: main
Are you sure you want to change the base?
Conversation
@@ -12,13 +12,13 @@ | |||
*/ | |||
package org.flowable.engine.impl.util; | |||
|
|||
import com.fasterxml.jackson.databind.node.ObjectNode; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do not change the ordering of the imports from the standards for this project. See for example the top of this file: https://github.com/flowable/flowable-engine/blob/main/ide-settings/idea/idea-code-style-configuration.xml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks for the link, will update to match project code style.
In some rare cases the BpmnModel can change between the call to "containsSignalId" and the call to get the signal, causing an NPE if the signal was no longer available on the model. Due to the way containsSignalId is implemented, the call to it is entirely unnecessary in these cases.
a6d9f7f
to
0d25055
Compare
@ikaakkola can you please provide some tests cases for this NPE? We would like to see why it fails. |
I have not been able to reproduce this in unit tests, but have witnessed NPE in production for this ; that is, the BpmnModel signals were changed by another thread between the two calls (bpmnModel.containsSignalId() and the subsequent bpmnModel.getSignal() call) which is entirely possible as there is no synchronization of any sorts here. The change simply removes the entirely unnecessary step of getting the signal twice - containsSignalId() calls provide no additional functionality as opposed to simply getting the signal and then checking if it was not null before using the signal. It is very difficult to get this to happen in a junit test due to the fact that the BpmnModel needs to be changed between two subsequent function calls, but that doesn't mean it cannot happen. |
Here is a stack trace showing this happen (Flowable 6.7.2) , the in-house ExtendedProcessRuntimeService.java parts are not really relevant here, the failure happens after calling https://github.com/flowable/flowable-engine/blob/flowable-6.7.2/modules/flowable-engine/src/main/java/org/flowable/engine/impl/util/ProcessInstanceHelper.java#L415 (signal.getName() throws as signal is null)
|
In some rare cases the BpmnModel can change between the call to "containsSignalId" and the call to get the signal, causing an NPE if the signal was no longer available on the model.
Due to the way containsSignalId is implemented, the call to it is entirely unnecessary in these cases.