Hi! My team and I have similar concern as @sgehrig regarding Registry being marked @internal.

We are using Registry to resolve workflow in runtime for each individual instance, and for that we created a custom implementation of WorkflowSupportStrategyInterface.

I'll provide a simplified explanation of our use case, so you could better understand why we would need that :)

Lets imagine a service that aggregates some financial products (insurance, bank loans, etc..) provided by some financial organizations. This service implements an integration with each partner (financial organizations). Each partner has it's own API and it's own process how exactly (step by step) a customer (end user) can get a bank loan from that partner.

So, lets say in that service we have an entity called Deal, a simplified implementation below:

#[ORM\Entity(repositoryClass: DealRepository::class)]
class Deal
{
    #[ORM\Id]
    #[ORM\Column(type: 'ulid', unique: true)]
    private Ulid $id;

    #[ORM\ManyToOne(fetch: 'EAGER')]
    #[ORM\JoinColumn(nullable: false)]
    private Integration $integration;

    #[ORM\Column(type: 'json')]
    private array $states = [];

    public function getId(): Ulid
    {
        return $this->id;
    }

    public function getIntegration(): Integration
    {
        return $this->integration;
    }

    public function setIntegration(Integration $integration): self
    {
        $this->integration = $integration;

        return $this;
    }

    public function getStates(): array
    {
        return $this->states;
    }

    public function setStates(array $states): self
    {
        $this->states = $states;

        return $this;
    }
}

Methods getStates() and setStates() are the methods used by MarkingStore to read/write object's state. The Deal can be at multiple places (states) at a time.

Deal has a relation to Integration entity which contains some information about the integration with a specific partner. An integration has a unique name, and a unique integration code.

The integration process (workflow) with all partners is different in general, but there are some common operations that appear in all integrations (create a Deal entity within our service, send initial user data to partner, upload user documents, etc.)

There are API endpoints for all these common operations that define all possible interactions with our customer (end user). In these API endpoints (besides other business logic which is the same for all integrations) we, eventually, resolve Deal workflow in runtime and apply a common transition (which exists in each integration's workflow). Deal workflow depends on what product from what partner the customer has selected.

// somewhere within API endpoint's logic (exceptions handling omitted for simplicity)
$dealWorkflow = $this->workflowRegistry->get($deal);
$dealWorkflow->apply($deal, 'InitDeal');

There are few key points to take into account:

1. To resolve workflow we have a custom implementation of \Symfony\Component\Workflow\SupportStrategy\WorkflowSupportStrategyInterface that compares integration_code defined in workflow metadata and integration code of the given Deal entity ($deal->getIntegration()->getCode()).

final class IntegrationCodeSupportStrategy implements WorkflowSupportStrategyInterface
{
    public function supports(WorkflowInterface $workflow, object $subject): bool
    {
        return $subject instanceof Deal
            && $workflow->getMetadataStore()->getMetadata('integration_code') === $subject->getIntegration()->getCode();
    }
}

2. A transition named InitDeal is defined in each workflow, but the definition is different (to place(s) might be different)
3. The business logic around InitDeal transition is different for each integration, and that logic is implemented via event subscribers for each specific workflow.

So, basically, we have multiple workflows that look similar to this:

framework:
    workflows:
        some_partner_deal:
            type: 'workflow'
            support_strategy: 'app.workflow.integration_code_supports_strategy' # custom supports strategy
            metadata:
                integration_code: 'some_partner_integration_code' # this code is unique for all integrations
            initial_marking: 'new'
            places:
                'new': ~
                'foo': ~
                'bar': ~
                # other places...
            transitions:
                'InitDeal': # this transition gets applied within an API endpoint reused in all integrations with all partners 
                    from: 'new'
                    to: 'foo'
                'SomePartnerSpecificTransition': # this transition gets applied somewhere in partner-specific integration code
                    from: 'foo'
                    to: 'bar'
                # other transitions...

The real usage is more complex but I hope this should be enough to explain why we use \Symfony\Component\Workflow\Registry.

I'm sure we are not the only team who finds it useful, at least since what @sgehrig described in this discussion sounds like he has something similar. And there are many devs still using Symfony 5.4 and have no clue what changes are coming in 6.2+ - they might also share some interesting use cases...

@lyrixx You proposed using service locators instead of Registry.

I thought it over, so, yes, it's possible with some restrictions, and I guess it would look similar to this:

class WorkflowResolver
{
    private ContainerInterface $workflowLocator;

    public function __construct(#[TaggedLocator('workflow')] ContainerInterface $workflowLocator) {
        $this->workflowLocator = $workflowLocator;
    }

    public function resolve(Deal $deal): WorkflowInterface
    {
        // to get a workflow instance from service locator we do need the workflow name, no other options here..
        // so I imagine we would have to use integration code as a part of workflow name
        $workflowName = sprintf('%s_deal', $deal->getIntegration()->getCode());

        // and then we just get the required workflow by its name
        // looks quite simple, right?
        return $this->workflowLocator->get($workflowName);
    }
}

But if you take a closer look, you may note this approach (WorkflowResolver) does essentially the same thing what a WorkflowSupportStrategyInterface is intended for - it implements the way how we define what workflow supports what Deal objects, and retrieves the workflow from service locator.

We could do the same by implementing a WorkflowSupportStrategyInterface:

final class IntegrationCodeSupportStrategy implements WorkflowSupportStrategyInterface
{
    public function supports(WorkflowInterface $workflow, object $subject): bool
    {
        return $subject instanceof Deal
            && $workflow->getName() === sprintf('%s_deal', $subject->getIntegration()->getCode());
    }
}

... and still use Registry::get() instead of WorkflowResolver::resolve().

Basically WorkflowResolver is a limited version of the Registry. Registry in combination with WorkflowSupportStrategyInterface is more flexible and allows you to implement more complex support strategies.

So, I see 2 disadvantages comparing to existing functionality:

1. Using service locators the only option we have is to come up with some specific rules when giving names to our workflows.
2. The approach with service locators should be implemented as a custom solution in specific projects (thought before it was a part of the component out of the box)

The main question is simple: Why? What is the reason to mark Registry as @internal?

As @sgehrig already mentioned, having WorkflowSupportStrategyInterface makes no sense without Registry, so this should also be marked @internal? And what's next? Deprecated and eventually removed? Just for simplicity?

In my experience I didn't have any issues with Registry and WorkflowSupportStrategyInterface approach. I find this concept useful (I mean the support strategy itself assigned to a specific Workflow).

Some extra thoughts: if the Core Team wants to get rid of Registry for some reason, maybe we could keep the idea of supports strategies by making the WorkflowSupportStrategyInterface to be a dependency for the Workflow itself?
Within Workflow we could call the support strategy to know if the given object is actually supported by the workflow.
We could also expose a public method like Workflow::supports(object $subject) that could be used in combination with tagged iterator to resolve workflow for objects in runtime and still have the flexibility of WorkflowSupportStrategyInterface?

The strategy could be optional, by default workflow would support all objects (in fact as it is now, devs are free to pass any object to a workflow instance, which is a good place for potential human mistakes.. so maybe it would be even better to have some built-in object check within Workflow, I guess a default check like instanceof would not result in notable performance decrease).

Not sure if it makes any sense for anyone, but thanks for taking time to read all this! :)

Hi @lyrixx

I just upgraded my project and this change broke it.
Here's how I am using the registry with API Platform (very generic implementation)

a) I have a compiler pass, that looks for the addWorkflow method call in registry and prepares a list of entities that have a workflow

b) Then I have a factory that creates 2 new endpoints for these entities at runtime.

• 1 to get the enabled transitions (GET operation)
• 2 to apply transition (PATCH operation)

(I would have no idea about the workflow names here!)

c) Then I have listeners who listen to these operations and perform the transitions.

(I would have no idea about the workflow names here too)

For the step c I could use a service locator as you have described above, but how do you suggest I go about steps (a) and (b)