[Workflow] Allow to define workflow with PHP attributes - #61935

Having a compiler pass defined in the component that processes a parameter storing the semantic configuration of FrameworkBundle leads to new BC guarantees we need to provide, as it means that this config is not purely internal anymore. It crosses a package boundary.
I would prefer keeping the FrameworkBundle config structure purely internal (we provide BC for the input of our Configuration classes, not for its output, as this would forbid us to make many changes we do when deprecating things)

So I need to create a shape that is stored in the component, and the framework bundle will convert its internal structure to that shape?

LGTM

why is the name part of the configuration attribute while used separately, instead of being a separate tag attribute ?

I don't understand you sentence :/

The PHP attribute looks like this:

#[AsWorkflow(
    name: 'task',
)]

It's converted to an array of configuration, and it's passed as a DIC attribute of the tag:

$container->registerAttributeForAutoconfiguration(AsWorkflow::class, static function (ChildDefinition $definition, AsWorkflow $attribute, \ReflectionClass $reflection) use ($attributeReader): void {
    $configuration = $attributeReader->extractConfiguration($attribute, $reflection);
    $definition->addTag('.workflow.attribute', [
        'configuration' => $configuration,
    ]);
});

On the line you commented, the name part is coming from the configuration.

why clearing this tag ? That definition created just above will not have this tag.

It's not needed anymore. It's just internal stuff. There is no need to expose that, and have to maintain a BC on this

getTraitNames() only reports traits used directly by the class, so a class that picks WorkflowTrait up from a parent or from another trait never gets the setWorkflow() call: abstract class Base { use WorkflowTrait; } with #[AsWorkflow(name: 'task')] class TaskWorkflow extends Base {} compiles with state_machine.task created and zero method calls on the service, then throws "The workflow has not been set" on the first apply(). You could test $reflection->hasMethod('setWorkflow') instead, or walk the parents and the traits of traits.

This early return turns every #[AsWorkflow] class into a silent no-op when workflow.registry is absent, and framework.workflows is canBeEnabled() so it is off by default. An app configured through attributes alone compiles with the .workflow.attribute tag still on the definition, no workflow service and no setWorkflow() call, so it may be worth throwing here when tagged services exist, with a message naming framework.workflows.enabled.

Service ids come from type and name alone, so two workflows sharing both collapse into one set of definitions with no diagnostic: two classes carrying #[AsWorkflow(name: 'task')] yield a single state_machine.task holding the second class's transitions, while the registry gets addWorkflow for both supports classes pointing at it. Guarding with $container->hasDefinition($workflowId) and throwing on a collision would surface it at compile time.

Normalization emits a weighted key while the consumer reads $arc['weight'] ?? 1 and the YAML arc schema also uses weight, so any weight expressed on an attribute arc is dropped when Arc is built. Renaming the key to weight would align the two paths, and AttributeReaderTest needs the matching assertion since it currently pins weighted.

auditTrail defaults to true while the audit_trail config node is canBeEnabled() and off by default, so #[AsWorkflow(name: 'task', supports: [...])] alone registers an AuditTrailListener on leave, transition and enter. Defaulting to false would keep the two configuration formats behaving the same.

This drops the array $context parameter that Workflow::getMarking() accepts, and getEnabledTransition() has no delegation at all even though WorkflowInterface declares it on the target branch. Code moving from an injected WorkflowInterface to the trait loses both and cannot reach the private $workflow, so mirroring the current interface signatures here would help.

Both places exceptions interpolate self::class, which renders as the attribute FQCN rather than the workflow being configured, so a bad places string fails with a message naming Symfony\Component\Workflow\Attribute\AsWorkflow and never the offending class. Using $this->name would point at the right workflow.

Normalization fills in metadata for string places only, so places: [['name' => 'draft']] reaches if ($place['metadata']) in WorkflowServiceCreatorPass and raises an "Undefined array key" warning during compilation. Applying $place['metadata'] ??= [] in the array branch covers it.

Both sides are sorted lists of strings and compare identical under === on this branch, so switching to assertEquals only loosens the check without fixing anything. You can keep assertSame here.

The third scan already discovers .workflow.attribute from the findTaggedServiceIds('.workflow.attribute', true) call in WorkflowServiceCreatorPass, which sits under a DependencyInjection path inside src/Symfony. Dropping the hardcoded entry keeps the list honest if the tag later loses its consumer.