-
Notifications
You must be signed in to change notification settings - Fork 177
Prohibit use of WorkflowClient from workflow code #556
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
Conversation
8cc7d1b
to
10fe892
Compare
efb03ff
to
faad949
Compare
5df6ab7
to
26001c2
Compare
WorkflowServiceStubs service, WorkflowClientOptions options) { | ||
return new WorkflowClientInternal(service, options); | ||
enforceNonWorkflowThread(); | ||
return WorkflowThreadMarker.protectFromWorkflowThread( |
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.
We should consider adding an option that would disable this enforcement. If users are already running "bad" workflows in production, then there should be a way to disable this feature until workflows are refactored/updated, otherwise we are forcing users to stay on older SDK versions.
(proxy, method, args) -> { | ||
// you make your check here | ||
if (isWorkflowThread()) { | ||
throw new IllegalStateException("Cannot be called from workflow thread."); |
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 add details to the error message with which function and on which class has been called.
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.
Why do we need it in the message if this will be in a stacktrace?
temporal-testing/src/main/java/io/temporal/testing/TestActivityEnvironmentInternal.java
Outdated
Show resolved
Hide resolved
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.
LGTM overall, as mentioned above, I would add a feature flag to provide backwards compatibility option for existing workflows.
…kflowServiceStubs from workflow code
What was changed
Now the usage of
WorkflowClient
,ActivityCompletionClient
, andWorkflowServiceStubs
is prohibited from workflow code.It's an alternative PR to the original PR #550.
The main difference is that this PR doesn't rely on magic thread names to understand that we are inside a workflow thread, but a marker utility class was implemented that is published by DeterministicRunner and available to serviceclient code.
It includes a fix for
TestActivityEnvironmentInternal
to execute activities code in a separate thread pool, not in a main thread of DeterministicRunnerImpl to emulate the behavior of our real worker setup and allow a correct work of implemented checks for ActivityCompletionClient (this class is actively used in activities code)Also, this PR uses proxies to
WorkflowClient
,ActivityCompletionClient
, andWorkflowServiceStubs
instancesWhy?
New users might not be aware of nondeterministic requirements and might use WorkflowClient and Activity interfaces from the workflow code.
Closes #402