This legacy 1.x release adds WorkflowOptions::overlapReleaseAfter for workflows whose queued jobs contend on an overlap lock, including the database-queue failure reported in #897.
use Workflow\WorkflowOptions;
use Workflow\WorkflowStub;
$workflow = WorkflowStub::make(MyWorkflow::class);
$workflow->start('argument', new WorkflowOptions(
connection: 'database',
overlapReleaseAfter: 5,
));The delay is a nonnegative integer in seconds. WorkflowOptions::set(['overlapReleaseAfter' => 5]) also accepts it. It applies to contended workflow, activity, signal and child-result queue jobs, and is preserved through child inheritance and continue-as-new unless explicit options replace it. Lock ownership and expiry are unchanged.
The default remains zero. Existing runs keep their stored options, so updating the package alone does not enable a delay. Laravel queue reservations still count as attempts; choose a delay and retry budget for the expected contention duration. This setting does not reset an existing job's attempts or make arbitrarily low attempt limits safe.
Allow the 1.1 line in the application's Composer constraint and restart long-running workers through the application's normal deployment process. No schema migration is added.
Qualification: full ECS/PHPStan, 418 unit tests, 100% statement coverage, PostgreSQL features, MySQL database-queue and concurrency controls, and hosted Laravel 9–13 dependency-injection checks pass. See #904 for exact results. The merged source tree is identical to the qualified candidate.
Usage guide. Current 2.x delivery continues in #903; #897 remains open through installed-package acceptance and that follow-through.