Skip to content
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

Workflow-init support #480

Open
drewhoskins-temporal opened this issue Aug 2, 2024 · 4 comments
Open

Workflow-init support #480

drewhoskins-temporal opened this issue Aug 2, 2024 · 4 comments

Comments

@drewhoskins-temporal
Copy link

We should have a method that's guaranteed to initialize before signals and updates come in so handlers can use initialized values.

@josh-berry
Copy link

see the parent feature issue for how other languages have handled it: temporalio/features#400

@roxblnfk
Copy link
Collaborator

I'm developing the concept of Workflow Init in the constructor: the user can call the Workflow::getInput() method to obtain input arguments.

    public function __construct() {
        $input = Workflow::getInput()->getValues();
        // ... init code
    }

However, getInput() returns a ValuesInterface, which does not contain type information.

Manually specifying the type for required arguments like Workflow::getInput()->getValue(0, DateTimeInterface::class); is inconvenient.
Additionally, new objects will be created instead of reusing existing ones.

My proposal is to add a new method Workflow::getTypedInput(), which will return the same arguments that will be sent to the Workflow Handler after initialization.
This way, we can provide a convenient Workflow Init using language mechanisms. At the same time, we still have the flexibility to add a separate InitHandler if needed.

@Sushisource
Copy link
Member

@roxblnfk That works for me. If it's possible to allow them to specify the args in their constructor, and pass them in there I would say let's do that (possibly in addition to getTypedInput), possibly by using an annotation on the constructor like we've done for Python. If that's not feasible I think this approach will work just fine too.

@drewhoskins-temporal
Copy link
Author

drewhoskins-temporal commented Oct 1, 2024

+1 to @Sushisource's comment, if it's doable. It seems somewhat more discoverable and idiomatic.

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

No branches or pull requests

4 participants