Releases: temporalio/sdk-php
v2.17.1
What's Changed
Full Changelog: v2.17.0...v2.17.1
Contributors
Assets 2
v2.17.0
Temporal PHP SDK v2.17.0
This release focuses on better observability, improved error handling, clearer APIs, and significantly enhanced testing & CI reliability.
Several deprecations were introduced to improve long-term API consistency.
Features
Expose FirstRunId & OriginalRunId in WorkflowInfo
WorkflowInfo now exposes:
getFirstRunId()getOriginalRunId()
This improves traceability across retries, resets and continue-as-new chains.
$info = Workflow::getInfo();
$firstRun = $info->getFirstRunId();
$originalRun = $info->getOriginalRunId();This is particularly useful for observability tooling and debugging long-running workflow chains.
Workflow Current Details Support
Workflows can now expose structured “current details” metadata, improving runtime inspection and debugging of workflow state.
Expose Retry Policy in Activity Context
Activities can now access their configured retry policy:
$context = Activity::getContext();
$retryPolicy = $context->getRetryOptions();This enables dynamic behavior depending on retry configuration.
ApplicationFailure ErrorCategory Exposure
ApplicationFailure now exposes ErrorCategory, allowing more precise error classification and handling logic in workflows.
RawValue Implementation
Introduced RawValue for pass-through or untyped payload handling.
Useful when custom serialization control is required.
Environment Configuration Exposure
Improved environment configuration visibility and integration, especially useful for CI and containerized deployments.
Windows Test Runner Wrapper
Added a wrapper to properly handle non-zero exit codes on Windows systems.
Improves cross-platform development and CI reliability.
Deprecations
Activity Method Without #[ActivityMethod] Attribute
Using an activity method without the required #[\Temporal\Activity\ActivityMethod] attribute now triggers a deprecation warning.
#[\Temporal\Activity\ActivityMethod]
public function sendEmail(): void
{
// ...
}This ensures explicit activity registration and prevents subtle misconfiguration.
Tip
You may disable this behavior with the feature flag \Temporal\Worker\FeatureFlags::$warnOnActivityMethodWithoutAttribute
See https://github.com/temporalio/sdk-php/blob/962c897757d9e9c29d579edb12c94e01b1c6fd52/src/Worker/FeatureFlags.php#L66C25-L66C61
Improvements
Friendly Outbound Context Exception
Improved error messages when workflow/activity context is misused outside its valid execution scope.
Exceptions are now more descriptive and actionable.
Improved DX for WorkflowRunInterface::getResult($type)
Improved typed result retrieval and clearer error feedback when incorrect types are requested.
DateInterval Ambiguity Warning
Improved handling and warnings for ambiguous DateInterval usage to avoid subtle time calculation inconsistencies.
Improved Priority Validation
Enhanced validation in Priority::withFairnessWeight() with stricter guarantees and additional test coverage.
More Lenient Search Attribute Parsing
Search attribute parsing is now more tolerant to slightly variant input types, improving robustness.
More Informative Error Messages
General improvement of error clarity across workflow and activity contexts.
Fixes
Correct Exception Types from Activity & Workflow Contexts
Ensures correct exception propagation and typing consistency.
Sync with Default PHP Timezone
Fixes mismatch between Temporal runtime behavior and PHP default timezone.
Fix PHP 8.4 Deprecations in Tests
Ensures forward compatibility with PHP 8.4.
Upgrade symfony/process Minimum Version
Minimum supported version bumped to 5.4.51.
CODEOWNERS Syntax Fix
PR: #712
Author: @mjameswh
(New contributor)
Testing & CI Improvements
-
Acceptance tests split into Fast / Slow
PR: #708
Author: @xepozz -
Use IP instead of localhost in tests
PR: #713
Author: @xepozz -
Allow continue-on-error in validate-prefer-lowest
PR: #696
Author: @xepozz
Platform & Dependency Updates
Documentation
Full Changelog
Contributors
Assets 2
v2.16.0
Warning
RoadRunner 2025.1.3+ is required.
Abandoned Child Workflow Cancellation
Added a new feature flag FeatureFlags::$cancelAbandonedChildWorkflows to control the cancellation behavior of abandoned Child Workflows.
Previously, when a parent workflow was canceled, all child workflows would be canceled, including those with ParentClosePolicy::Abandon.
This behavior was incorrect - abandoned child workflows should continue running independently when their parent is canceled.
# worker.php
use Temporal\Worker\FeatureFlags;
// Fixed behavior (does NOT cancel abandoned children) - recommended
FeatureFlags::$cancelAbandonedChildWorkflows = false;
// Default behavior (cancels abandoned children - matches previous SDK versions)
FeatureFlags::$cancelAbandonedChildWorkflows = true;Warning
When setting $cancelAbandonedChildWorkflows = false:
- If you start an abandoned child workflow in the main workflow scope, it may miss the cancellation signal if you await only on the child workflow. Use
Promise::race()with a timer to properly handle cancellation. - If you start an abandoned child workflow in an async scope that is later canceled, the child workflow will not be affected by the scope cancellation.
- You can still cancel abandoned child workflows manually by calling
WorkflowStubInterface::cancel().
New Promises
The PHP SDK now supports React Promise v3.
To make this work correctly in the Workflow Worker environment,
the promises have been forked and improved in the internal/promise package.
The fork addresses critical issues for long-running Workflow Workers:
made rejection handler reusable (a v3 feature),
removed exit(255) calls from rejection handling that would terminate the worker process,
added declare(strict_types=1) throughout, and improved type annotations for better static analysis support.
A key improvement is the @yield annotation added to PromiseInterface,
which enables proper type inference when using promises with generators in Workflows.
This annotation is recognized by IDEs (PHPStorm) and static analysis tools (Psalm), significantly improving DX:
interface SomeActivity {
/**
* @return \React\Promise\PromiseInterface<ResultDto>
*/
public function doSomething(int $value): ResultDto;
}
final class Workflow {
public function handle(): \Generator
{
$activity = \Temporal\Workflow::newActivityStub(SomeActivity::class);
$result = yield $activity->doSomething(42); // IDE and Psalm infer $result as ResultDto
}
}The SDK supports both React Promise v2 and v3 - the version used depends on what you require in your composer.json.
Warning
React Promise v3 includes optimizations that may slightly change promise resolution order compared to v2. This could potentially affect Workflow determinism in edge cases.
If you experience issues after upgrading, lock to React Promise v2 in your composer.json:
{
"require": {
"react/promise": "^2.11"
}
}Destroyable Interface
Workflows can now implement the Destroyable interface from the internal/destroy package to explicitly manage resource cleanup when the Workflow instance is evicted from memory.
This is particularly useful when your Workflow contains circular references between objects that prevent PHP's garbage collector from properly cleaning up memory.
While this is not a common scenario,
having explicit control over resource cleanup is critical for long-running Workers handling many workflow executions.
The SDK automatically calls the destroy() method when a Workflow instance needs to be evicted from memory,
allowing you to break circular references and release resources deterministically.
final class Workflow implements Destroyable
{
/** Collection with cross-linked objects that also implements Destroyable */
private LinkedCollection $collection;
// ...
public function destroy(): void
{
// Must be idempotent - safe to call multiple times
$collection = $this->collection ?? null;
unset($this->collection);
$collection?->destroy();
}
}Enhanced Workflow Info
Added new fields to Workflow::getInfo():
- Access the root Workflow execution from any Workflow in the execution chain, including deeply nested child Workflows.
- Access the Workflow's retry policy directly from the Workflow Context.
$rootExecution = Workflow::getInfo()->rootExecution;
$retryOptions = Workflow::getInfo()->retryOptions;RoadRunner PSR Logger
The RoadRunner ecosystem now includes a new roadrunner/psr-logger package that can be used with Temporal SDK.
By default, the SDK uses \Temporal\Worker\Logger\StderrLogger which outputs messages to STDERR.
RoadRunner captures these messages and logs them at the INFO level.
The new \RoadRunner\PsrLogger\RpcLogger sends logs to RoadRunner via RPC with precise log levels and structured context data.
Get Started:
composer require roadrunner/psr-loggeruse RoadRunner\PsrLogger\RpcLogger;
use Spiral\Goridge\RPC\RPC;
use Temporal\WorkerFactory;
$rpc = RPC::create('tcp://127.0.0.1:6001');
$logger = new RpcLogger($rpc);
$factory = WorkerFactory::create(logger: $logger);
$worker = $factory->newWorker('my-task-queue');New Worker Versioning (experimental)
Worker Versioning enables safe deployment of workflow changes by controlling how Workflows move between different worker versions.
Each worker deployment is identified by a unique Build ID, and workflows can be pinned to specific versions or automatically upgrade to the latest version.
Worker Configuration
Configure versioning when creating a worker:
use Temporal\Worker\WorkerOptions;
use Temporal\Worker\WorkerDeploymentOptions;
use Temporal\Common\Versioning\VersioningBehavior;
$worker = $factory->newWorker(
'my-task-queue',
WorkerOptions::new()
->withDeploymentOptions(
WorkerDeploymentOptions::new()
->withUseVersioning(true)
->withVersion('build-v1.2.3')
->withDefaultVersioningBehavior(VersioningBehavior::Pinned)
)
);Workflow Versioning Behavior
Control versioning behavior per workflow using the #[WorkflowVersioningBehavior] attribute:
use Temporal\Workflow;
use Temporal\Common\Versioning\VersioningBehavior;
#[Workflow\WorkflowInterface]
class MyWorkflow
{
#[Workflow\WorkflowMethod]
#[Workflow\WorkflowVersioningBehavior(VersioningBehavior::Pinned)]
public function handle(): \Generator
{
// Workflow will stay pinned to its original deployment version
yield Workflow::timer(3600);
return 'Done';
}
}Versioning Behaviors:
Pinned: Workflow stays on its original deployment version until completionAutoUpgrade: Workflow automatically moves to the current deployment version on the next workflow task
Client Override
Override versioning behavior when starting a workflow:
use Temporal\Client\WorkflowOptions;
use Temporal\Common\Versioning\VersioningOverride;
use Temporal\Common\Versioning\WorkerDeploymentVersion;
// Pin to specific version
$workflow = $client->newWorkflowStub(
MyWorkflow::class,
WorkflowOptions::new()
->withVersioningOverride(
VersioningOverride::pinned(
WorkerDeploymentVersion::fromString('build-v1.2.3')
)
)
);
// Or enable auto-upgrade
$workflow = $client->newWorkflowStub(
MyWorkflow::class,
WorkflowOptions::new()
->withVersioningOverride(VersioningOverride::autoUpgrade())
);Note
This feature is experimental and requires RoadRunner 2025.1.3+.
See the Worker Versioning documentation for deployment strategies and best practices.
Priority Fairness (experimental)
Priority Fairness extends the Task Queue Priority feature with fairness keys and weights,
enabling balanced task processing across multiple tenants or execution groups within a single task queue.
This is particularly valuable for multi-tenant SaaS applications where you need to prevent large tenants from monopolizing worker resources.
Key Concepts:
- Fairness Key: A short string (up to 64 bytes) that groups tasks together, typically representing a tenant ID or priority band (e.g., "premium", "standard", "free")
- Fairness Weight: A float value (0.001 to 1000) that controls the relative processing share for each fairness key. Higher weights receive proportionally more throughput
The fairness mechanism ensures tasks are dispatched in proportion to their weights. For example, with 1000 tenants each having a weight of 1.0, each tenant receives roughly equal task processing throughput regardless of their individual workload size.
Setting Fairness Parameters:
use Temporal\Common\Priority;
use Temporal\Client\WorkflowOptions;
// Start workflow with fairness settings
$workflow = $workflowClient->newWorkflowStub(
OrderWorkflow::class,
WorkflowOptions::new()
->withTaskQueue('task-queue')
->withPriority(
Priority::new()
->withFairnessKey('tenant-123')
->withFairnessWeight(2.5)
),
);In Workflow Context:
use Temporal\Workflow;
use Temporal\Common\Priority;
// Set f...Contributors
Assets 2
v2.15.1
What's Changed
- Remove experimental note from
updateWithStart()client method by @roxblnfk in #637 - Bugfix: send a special request to RR if the calling Workflow was not found by @roxblnfk in #639
Full Changelog: v2.15.0...v2.15.1
Contributors
Assets 2
v2.15.0
Warning
RoadRunner 2025.1.2 is required.
Task Queue Priority
Task Queue Priority allows you to control the execution order of workflows, activities, and child workflows based on assigned priority values within a single task queue. You can select a priority level in the integer range 1...5. A lower value implies higher priority. The default priority if unspecified is in the middle of the range, 3.
Note
As this feature is currently in Pre-release stage, it is not intended for production use at this time.
See product release stages for more information.
Pre-requisites
- If using Temporal Cloud, please contact Temporal support or your Temporal account team to enable this feature for your cloud namespace(s).
- If self-hosting Temporal, use the latest pre-release development server and set
matching.useNewMatcherdynamic config on the relevant task queues (or namespaces).
Client API
# New Priority DTO
$priority = Priority::new(priorityKey: 1);
# Set Priority on a Workflow
$workflow = $workflowClient->newWorkflowStub(
OrderWorkflowInterface::class,
WorkflowOptions::new()
->withTaskQueue('task-queue')
->withPriority($priority),
);Workflow API
# New Priority DTO
$priority = Priority::new(priorityKey: 1);
# Set Priority on an Activity
$activity = Workflow::newActivityStub(
ActivityInterface::class,
ActivityOptions::new()
->withTaskQueue('task-queue')
->withStartToCloseTimeout('5 minutes')
->withPriority($priority),
);
# Set Priority on a Child Workflow
$childWorkflow = Workflow::newChildWorkflowStub(
ChildWorkflowInterface::class,
ChildWorkflowOptions::new()
->withTaskQueue('task-queue')
->withPriority($priority),
);Get Priority value in Workflow or Activity
// Get
$priority = Activity::getInfo()->priority;
$priority = Workflow::getInfo()->priority;Note
- Lower numbers = higher priority.
- Tasks with the same priority are scheduled in FIFO order.
- If priority is unsupported by the server, these settings are silently ignored.
- Remember this feature is not production ready at this stage.
User Metadata
Handler Descriptions
You can now add descriptions to Query, Signal, and Update handlers. Descriptions are available through the description parameter in QueryMethod, SignalMethod, and UpdateMethod attributes, as well as in the Workflow::registerSignal(), Workflow::registerQuery(), and Workflow::registerUpdate() methods. These descriptions will be displayed in the Temporal UI for better handler documentation.
Using Attributes:
#[QueryMethod('get_counter', description: 'Get the current counter value')]
public function getCounter(): int
{
return $this->counter;
}
#[SignalMethod('inc_counter', description: 'Increment the counter value')]
public function incCounter(): void
{
++$this->counter;
}Using Registration Methods:
Workflow::registerQuery('get_counter', $this->getCounter(...), 'Get the current counter value');
Workflow::registerSignal('increment_counter', $this->incrementCounter(...), 'Increment the counter value');Activity and Timer Summaries
You can now add custom metadata summaries to Activity and Timer executions. These summaries will be displayed in the Workflow history within the Temporal UI, providing better visibility into workflow execution details.
Activity Summary:
yield Workflow::executeActivity(
type: 'activity_type',
options: ActivityOptions::new()
->withScheduleToCloseTimeout(30)
->withSummary('Process user payment'),
);Timer Summary:
yield Workflow::timer(
interval: 30,
options: TimerOptions::new()->withSummary('Wait for external service response'),
);Activity Pause
When a heartbeating activity is paused, an ActivityPausedException will be thrown.
Added Activity::getCancellationDetails() that returns ActivityCancellationDetails DTO that provides the reasons for the activity's cancellation.
Pull Requests
- Null coalesce in AttributeMapper instead of try/catch by @shanginn in #615
- Fixed type WorkflowClientCallsInterceptor by @root-aza in #612
- Add versioning acceptance tests by @roxblnfk in #614
- Add Child Workflow ID test by @roxblnfk in #617
- Expose Priority by @roxblnfk in #607
- Expose metadata query support by @roxblnfk in #616
- Add PromiseInterface stub for IDE by @roxblnfk in #627
- Expose
summaryoption for timers and activities by @roxblnfk in #626 - Testing: fixed downloading of
temporal-test-serverfor arm64 by @root-aza in #629 - Fix prototype existence check in ArrayRepository by @roxblnfk in #631
- Process special Temporal builtin prefixes by @roxblnfk in #630
- Activity pause by @roxblnfk in #620
Full Changelog: v2.14.1...v2.15.0
Contributors
Assets 2
v2.14.1
Contributors
Assets 2
v2.14.0
Warning
RoadRunner 2024.3.3+ is required.
Workflow Logger
Logging is a critical component for monitoring and troubleshooting your Temporal applications. The PHP SDK now provides a dedicated logger for use within Workflows that respects replay semantics and adds contextual information automatically.
To get a PSR-3 compatible logger in your Workflow code, use the Workflow::getLogger() method:
use Temporal\Workflow;
#[Workflow\WorkflowInterface]
class MyWorkflow
{
#[Workflow\WorkflowMethod]
public function execute(string $param): \Generator
{
Workflow::getLogger()->info('Workflow started', ['parameter' => $param]);
// Your workflow implementation
Workflow::getLogger()->info('Workflow completed');
return 'Done';
}
}Replay Mode Behavior
An important feature of the Workflow logger is its replay-aware behavior. By default, logs are only emitted during the initial Workflow execution and are suppressed during replay to prevent duplicate log entries.
If you want to enable logging during replay (for debugging purposes), you can configure this with the enableLoggingInReplay option:
$factory = WorkerFactory::create();
$worker = $factory->newWorker('your-task-queue', WorkerOptions::new()
->withEnableLoggingInReplay(true)
);Automatic Context Enrichment
The Workflow logger automatically enriches log entries with the current task queue information. Every log message will include a task_queue key in its context, making it easier to filter and correlate logs.
For example, if a log statement is:
$logger->info('Processing order', ['order_id' => 123]);The actual logged context will be:
{ "task_queue": "your-task-queue", "order_id": 123 }
This happens automatically without any additional configuration.
Default Logger
By default, the PHP SDK uses a StderrLogger that outputs log messages to the standard error stream.
These messages are automatically captured by RoadRunner and incorporated into its logging system with the INFO level, ensuring proper log collection in both development and production environments.
For more details on RoadRunner's logging capabilities, see the RoadRunner Logger documentation.
Using a Custom Logger
You can configure your Temporal worker to use a custom PSR-3 compatible logger implementation:
$myLogger = new MyLogger();
$workerFactory = WorkerFactory::create(converter: $converter);
$worker = $workerFactory->newWorker(
taskQueue: 'my-task-queue',
logger: $myLogger,
);Your custom logger will be used throughout the Temporal SDK, including for Workflow logging when accessed through Workflow::getLogger().
getInstance() in Context
Added Activity::getInstance() and Workflow::getInstance() methods to get the current Activity and Workflow instances.
Changed workflow execution flow:
- First, the Workflow is initialized. The
__construct()method is called.- If the
#[WorkflowInit]attribute is present, the handler's arguments are resolved and passed to the constructor. - There you can't make calls to start Activity, ChildWorkflow, Timer, etc.
- If the
WorkflowInboundCallInterceptor::execute()is called- Arguments from the previous step are used, but they can be overridden for the handler call.
- You can call Activity, ChildWorkflow, Timer, etc.
Workflow::getInstance()returns the initialized Workflow instance.- Now errors from this step are recorded in the Workflow history.
- Workflow Handler is called.
Dynamic Handlers
Added methods to define dynamic handlers for Signals, Updates, and Queries that will be called if a handler for a specific name is not found.
// Dynamic Query Handler
\Temporal\Workflow::registerDynamicQuery(function (string $name, ValuesInterface $arguments): string {
return \sprintf(
'Got query `%s` with %d arguments',
$name,
$arguments->count(),
);
});
// Dynamic Update Handler
\Temporal\Workflow::registerDynamicUpdate(
static fn(string $name, ValuesInterface $arguments): string => \sprintf(
'Got update `%s` with %d arguments',
$name,
$arguments->count(),
),
static fn(string $name, ValuesInterface $arguments) => \str_starts_with(
$name,
'update_',
) or throw new \InvalidArgumentException('Invalid update name'),
);User Metadata Support in Client API
Added support for user metadata in Workflow Start/Schedule methods, improving the ability to attach additional information to workflow executions.
- Added ExecutionConfig with UserMetadata in Workflow Description
- Added support for user metadata in Workflow Start/Schedule methods. Metadata in Timers and Activities require changes in RoadRunner and can be added in the future.
Client API
use Temporal\Client\GRPC\ServiceClient;
use Temporal\Client\ScheduleClient;
use Temporal\Client\Schedule\Action\StartWorkflowAction;
use Temporal\Client\WorkflowClient;
use Temporal\Client\WorkflowOptions;
$serviceClient = ServiceClient::create('127.0.0.1:7233');
// Start Workflow with user metadata
$workflowClient = WorkflowClient::create($serviceClient);
$stub = $workflowClient->newUntypedWorkflowStub(
'SimpleWorkflow',
(new WorkflowOptions())
->withStaticSummary('some text')
->withStaticDetails('details')
);
$workflowClient->start($stub);
// Describe workflow
echo $stub->describe()->config->userMetadata->summary;
echo $stub->describe()->config->userMetadata->details;
// Schedule Workflow with user metadata
$scheduleClient = ScheduleClient::create($serviceClient);
$schedule = $scheduleClient->createSchedule(
\Temporal\Client\Schedule\Schedule::new()
->withAction(StartWorkflowAction::new(SimpleWorkflow::class)
->withStaticSummary('some-summary')
->withStaticDetails('some-details'))
);
// Describe schedule
$action = $schedule->describe()->schedule->action;
assert($action instanceof StartWorkflowAction);
echo $action->userMetadata->details;
echo $action->userMetadata->summary;Workflow context:
$stub = \Temporal\Workflow::newChildWorkflowStub(
SimpleWorkflow::class,
(new Workflow\ChildWorkflowOptions())
->withStaticSummary('some text')
->withStaticDetails('details')
);Additional Improvements
- Skip magic methods in Activity classes: Magic methods not marked by the ActivityMethod attribute will not be registered as activity methods
- Enhanced Workflow description info: Added new fields into Workflow stub -> describe result:
- rootExecution
- firstRunId
- executionDuration
Pull requests
- Features:
- Expose Activity and Workflow instance from context by @roxblnfk in #593
- Add methods to register fallback handlers by @roxblnfk in #581
- Add Workflow Logger by @roxblnfk in #589
- Skip magic methods in Activity classes by @roxblnfk in #572
- Update Workflow description info by @roxblnfk in #578
- Support UserMetadata in Client API by @roxblnfk in #585
- SDK Hotfixes:
- Maintenance
- Maintenance by @roxblnfk in #606
- Refresh and simplify CI Workflows by @roxblnfk in #600
- Add CODEOWNERS by @Sushisource in #604
- Fix vercel publishing by @Sushisource in #609
New Contributors
- @Sushisource made their first contribution in #604
- @DanielsStugis made their first contribution in #594
Full Changelog: v2.13.0...v2.14.0
Contributors
Assets 2
v2.13.4
What's changed
Full Changelog: v2.13.3...v2.13.4
Contributors
Assets 2
v2.13.3
What's Changed
Full Changelog: v2.13.2...v2.13.3
Contributors
Assets 2
v2.13.2
What's Changed
- Fix decoding of non-nullable interval fields when null is gotten from Temporal Cloud. By @roxblnfk in #570
Full Changelog: v2.13.1...v2.13.2