Skip to content

Conversation

Spikhalskiy
Copy link
Contributor

@Spikhalskiy Spikhalskiy commented Jun 25, 2021

What was changed

Now the usage of WorkflowClient, ActivityCompletionClient, and WorkflowServiceStubs 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

  • ensure the right type of a calling thread for each non-static method of WorkflowClient, ActivityCompletionClient, and WorkflowServiceStubs instances
  • decrease copy-paste
  • minimize mistakes in the future.

Why?

New users might not be aware of nondeterministic requirements and might use WorkflowClient and Activity interfaces from the workflow code.

Closes #402

@CLAassistant
Copy link

CLAassistant commented Jun 25, 2021

CLA assistant check
All committers have signed the CLA.

@Spikhalskiy Spikhalskiy marked this pull request as draft June 25, 2021 23:13
@Spikhalskiy Spikhalskiy force-pushed the thread-check branch 2 times, most recently from efb03ff to faad949 Compare July 7, 2021 00:34
@Spikhalskiy Spikhalskiy changed the title Prohibit use of WorkflowClient from workflow code - proposal Prohibit use of WorkflowClient from workflow code Jul 7, 2021
@Spikhalskiy Spikhalskiy marked this pull request as ready for review July 7, 2021 00:34
@Spikhalskiy Spikhalskiy force-pushed the thread-check branch 5 times, most recently from 5df6ab7 to 26001c2 Compare July 7, 2021 01:26
WorkflowServiceStubs service, WorkflowClientOptions options) {
return new WorkflowClientInternal(service, options);
enforceNonWorkflowThread();
return WorkflowThreadMarker.protectFromWorkflowThread(
Copy link
Contributor

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.");
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

@vitarb vitarb left a 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.

@Spikhalskiy Spikhalskiy merged commit 9a0a939 into temporalio:master Jul 8, 2021
@vkoby vkoby mentioned this pull request Aug 5, 2021
@Spikhalskiy Spikhalskiy deleted the thread-check branch April 15, 2022 20:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Prohibit use of WorkflowClient and Activity interfaces in workflow code.

3 participants