Skip to content

Conversation

@tim37021
Copy link

@tim37021 tim37021 commented Sep 30, 2021

I found ParentClosePolicy is not supported. Here's the PR.

Story

I am implementing proxy workflow pattern mention HERE
I want to launch a child workflow and the main workflow will finish earlier then it's child. Due to default parent close policy. The child workflow will be killed as well.

Result

without parent_close_policy

image

with parent_close_policy: :abandon

image

Usage

class ProxyWorkflow < Temporal::Workflow
  def execute(workflow_id)
    # copied from SDK example
    future = LongRunningActivity.execute(10, 1)
    workflow.execute_workflow(
      MainWorkflow,
      proxy_workflow_id: workflow_id,
      proxy_run_id: workflow.metadata.run_id,
      options: {
        parent_close_policy: :abandon,
      },
    )
    ret = nil
    workflow.on_signal do |signal, input|
      future.cancel
      ret = input
    end
    future.wait
    ret
  end
end
class MainWorkflow < Temporal::Workflow
  def execute(proxy_workflow_id:, proxy_run_id:)
    workflow.sleep(5)
    SignalActivity.execute!(proxy_workflow_id: proxy_workflow_id, proxy_run_id: proxy_run_id, input: "succsss yeah")
    10.times do
      HelloActivity.execute!("hehehe")
      workflow.sleep(1)
    end
  end
end

By the way, how can I know my workflow id? Currently I explicitly names it.

Temporal.start_workflow(TemporalWorkflow::ProxyWorkflow,  "hehehe", options: {workflow_id: "hehehe"})

@tim37021 tim37021 changed the title Add parent close policy Add ParentClosePolicy Sep 30, 2021
Copy link
Contributor

@antstorm antstorm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR. I've added a few comments, all should be easily addressable, but please let me know if you need any clarification.

Good call on getting the workflow_id when starting a workflow without explicitly providing it, we don't have a way to do that currently. We should probably return both a workflow_id and a run_id when scheduling a workflow, but that would be a breaking change

end

def validate!
unless %i[terminate abandon request_cancel].include?(@policy)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please define these as constants so they can be used without hardcoding symbols?

@namespace = options[:namespace]
@task_queue = options[:task_queue] || options[:task_list]
@retry_policy = options[:retry_policy] || {}
@parent_close_policy = options[:parent_close_policy] || {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ExecutionOptions are shared between workflows and activities, so this wouldn't be the best place to add workflow-specific options. Can you please move these inline with the child workflow invocation?

expect do
described_class.new(request_cancel_policy).to_proto
end.not_to raise_error
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please split these into 3 examples? It's easier to figure out which ones have failed that way

@tim37021
Copy link
Author

tim37021 commented Oct 17, 2021

Good call on getting the workflow_id when starting a workflow without explicitly providing it, we don't have a way to do that currently.

I think it's possible to not to have break change? instead of changing the interface.

I remember we have a run_id inside workflow.metadata
but it doesn't contains workflow_id currently. is it good to add that inside metadata?

@antstorm
Copy link
Contributor

antstorm commented Nov 1, 2021

@tim37021 yes, I was thinking that the most logical solution would be to return both workflow_id and run_id for a start_workflow call:

workflow_id, run_id = Temporal.start_workflow(MyWorkflow)

However exposing this via metadata still works, but I'm not sure how you're planning to get the metadata.

As for adding workflow_id to metadata — yes, that's something I've already implemented for cadence — coinbase/cadence-ruby#60, I'll replay that change over this repo today since others have asked about it as well

@antstorm
Copy link
Contributor

antstorm commented Nov 1, 2021

There we go — #110

@tim37021 tim37021 closed this Sep 19, 2022
calum-stripe pushed a commit to calum-stripe/temporal-ruby that referenced this pull request Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants