-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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(client) don't expose executionId to public API #4611
fix(client) don't expose executionId to public API #4611
Conversation
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.
Cool that we align the behavior with how we do it for process instance IDs. 👍
❌ Can we add a test for this?
Hi @tasso94, I have not tests for this fix for 2 reasons:
Let me what you think. |
Here are the tests: FileSerializationIT. Looking at this given you mainly have to copy what's there and maybe introduce another process model do you think it is doable? We can also pull this conversation on Slack 🙂 |
I added the new test to FileSerializationIT that already includes tests for I did not find a ci:label that would run the IT tests for java external client. |
Tests are executed in the assembly stage. |
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.
❓ When I revert the fix and run the new test, it doesn't fail. Why is that? 🤔
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.
❓ Can you add another test for #getVariableTyped
?
5ceb96d
to
3e1eed8
Compare
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.
❌ Now that we set the executionId
for DeferredFileValueImpl
, is there any situation where we use the processInstanceId
? If not, can we remove the getter and setters?
if(variableValue.getTypedValue() instanceof DeferredFileValueImpl) { | ||
DeferredFileValueImpl deferredFileValue = (DeferredFileValueImpl) variableValue.getTypedValue(); | ||
deferredFileValue.setExecutionId(this.executionId); | ||
} |
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.
❓ Can't we get rid of this code now that we pass the execution id to VariableValue
?
if(typedValue instanceof DeferredFileValueImpl) { | ||
DeferredFileValueImpl deferredFileValue = (DeferredFileValueImpl) typedValue; | ||
deferredFileValue.setExecutionId(this.executionId); | ||
} |
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.
❓ Can't we get rid of this code now that we pass the execution id to VariableValue
?
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.
Let me check.
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.
Looks good! 👍
Pushed a small code cleanup and converted your white into a black box test.
DeferredFileValueImpl typedValueImpl = (DeferredFileValueImpl) typedValue; | ||
assertThat(typedValueImpl.getExecutionId()).isEqualTo(task.getExecutionId()); |
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.
🔧 Let's keep using a white box test approach to a minimum. A black box should be the way to go.
We can fall back on white box tests only when a black box test is too difficult to achieve.
related to: #4523