WorkflowStub::make()->start() ignores workflows.v2.namespace while WorkflowControlPlane::start() applies it #617

Owning public component

Workflow engine

Exact version or source identity

2.4.0.

Minimal reproduction and evidence

Observed with durable-workflow/workflow 2.4.0 in a Laravel application using PostgreSQL and the database queue driver.

The package exposes DW_V2_NAMESPACE, mapped to workflows.v2.namespace.

Run the following after bootstrapping Laravel with the Workflow service provider registered:

use Illuminate\Support\Facades\Bus;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Str;
use Workflow\V2\Attributes\Type;
use Workflow\V2\Contracts\WorkflowControlPlane;
use Workflow\V2\Models\WorkflowInstance;
use Workflow\V2\Models\WorkflowRun;
use Workflow\V2\Workflow;
use Workflow\V2\WorkflowStub;

#[Type('namespace-probe')]
final class NamespaceProbeWorkflow extends Workflow
{
    public function handle(): string
    {
        return 'ok';
    }
}

Bus::fake();

$originalNamespace = config('workflows.v2.namespace');
config(['workflows.v2.namespace' => 'default']);

$stubId = 'namespace-probe-stub-' . Str::uuid();
$controlId = 'namespace-probe-control-' . Str::uuid();

DB::beginTransaction();

try {
    $started = WorkflowStub::make(
        NamespaceProbeWorkflow::class,
        $stubId,
    )->start();

    app(WorkflowControlPlane::class)->start(
        NamespaceProbeWorkflow::class,
        $controlId,
    );

    dump([
        'configured_namespace' => config('workflows.v2.namespace'),
        'stub_instance_namespace' => WorkflowInstance::query()
            ->findOrFail($stubId)->namespace,
        'stub_run_namespace' => WorkflowRun::query()
            ->findOrFail($started->runId())->namespace,
        'control_run_namespace' => WorkflowRun::query()
            ->where('workflow_instance_id', $controlId)
            ->firstOrFail()->namespace,
    ]);
} finally {
    DB::rollBack();
    config(['workflows.v2.namespace' => $originalNamespace]);
}

The equivalent probe was executed with an existing trivial application workflow. The observed values were:

{
  "configured_namespace": "default",
  "stub_instance_namespace": null,
  "stub_run_namespace": null,
  "control_run_namespace": "default"
}

The transaction was rolled back. A subsequent query confirmed that neither probe instance nor its runs remained in the database.

Source inspection also shows:

• src/config/workflows.php declares the namespace setting.
• DefaultWorkflowControlPlane::resolveNamespace() reads it.
• The inspected WorkflowStub::make()->start() path does not apply it when creating the instance and run.

Observed behavior

Setting workflows.v2.namespace does not produce consistent results across the two PHP start APIs:

• WorkflowStub::make()->start() creates an instance and run with namespace = NULL.
• WorkflowControlPlane::start() creates a run with the configured namespace.

There is a related operational consequence in our application: schedules use namespace = "default", while runs started through the stub path have namespace = NULL.

Filtering runs by the schedule's namespace therefore returns no matching executions, even though those executions exist and complete successfully.

This was initially visible in a read-only diagnostic tool. No execution failure was demonstrated; the confirmed problem concerns namespace assignment and namespace-filtered visibility.

Expected behavior and acceptance criteria

A configured namespace should have consistent semantics across supported PHP start APIs.

Acceptance criteria:

1. With workflows.v2.namespace = "default", a new instance and run created through WorkflowStub::make()->start() receive that namespace.
2. Cover both caller-supplied instance IDs and automatically generated IDs.
3. Verify namespace propagation to durable tasks where the namespace is part of the task contract.
4. Verify the standard PHP schedule-start path. A schedule's namespace and its execution namespace should follow an explicit, documented rule.
5. Preserve the documented behavior when no namespace is configured.
6. Define behavior when an existing instance belongs to a different namespace; do not silently reassign it.
7. Add regression tests comparing the stub and control-plane start paths.

If namespace configuration is intentionally unsupported by WorkflowStub, document that limitation explicitly and provide a supported way to start a namespaced PHP workflow through this API.

Existing records should not be rewritten implicitly as part of the fix.

Dependencies and related public issues

Affected package:

• durable-workflow/workflow 2.4.0

Verified application environment:

• PHP 8.4.24
• Laravel 13.34.0
• PostgreSQL 17
• Laravel database queue driver
• Redis cache

Relevant package components:

• Workflow\V2\WorkflowStub
• Workflow\V2\Contracts\WorkflowControlPlane
• Workflow\V2\Support\DefaultWorkflowControlPlane
• Workflow\V2\Support\ScheduleManager
• Workflow\V2\Support\PhpClassScheduleStarter

Relevant configuration:

• DW_V2_NAMESPACE
• workflows.v2.namespace

The discrepancy was reproduced directly through PHP APIs. Waterline and MCP are not required to reproduce it.

No related public issue has been confirmed for this namespace discrepancy.

Public intake checks

• I searched open and closed GitHub issues for an existing report.
• This report contains only public product context and redacted evidence.