Expose Activity and Workflow instance from context

[roxblnfk]

What was changed

• Added Activity::getInstance() and Workflow::getInstance()
• Changed workflow execution flow:
  • First, the Workflow is initialized.
    • It is recommended not to make calls to start Activity, ChildWorkflow, Timer, etc.
    • If the #[WorkflowInit] attribute is present, the arguments are resolved.
  • WorkflowInboundCallInterceptor::execute() is called
    • Arguments from the previous step are used, but they can be overridden.
  • Workflow Handler is called.
• Now errors from WorkflowInboundCallInterceptor::execute() are recorded in the Workflow history.

Tests:

• Acceptance Tests: added ability to customize workers per TaskQueue in tests.
• Added tests for workflow dynamic handlers.

Why?

Checklist

1. Closes [Feature Request] Access to workflow/activity instance from context #546
2. How was this tested: added tests
3. Any docs updates needed?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
php	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 1, 2025 0:32am

[Sushisource]

Something we do in the other SDKs is we actually run the init method in a special "readonly" context that will throw errors if the user attempts to issue any commands during init. I dunno if that's something that you can readily enforce, but if possible it's a nice bit of safety.

[roxblnfk]

Now any request from the constructor will throw an exception.

Workflow Context will no longer be readonly right after the init stage before the interceptor method WorkflowInboundCallsInterceptor::execute is run.