B5 and B6 — the first workflow registers, and the walkthrough leads somewhere

[gplanchat]

Documentation only, six files, two languages. No code.

B5 — the guide's first workflow did not register

The guide put #[AsActivity(name: …)] on the implementation class. Checked against the code: that attribute is read by ActivityContractResolver::resolveViaReflection() on the contract, as an optional naming prefix. On an implementation, nobody reads it.

Worse, it took the place of #[AsActivityHandler(contract: …)] — the only one of the two that DurableBundle::build() autoconfigures. Readers followed the guide to the letter and their class was never registered on the activity executor.

The real model, now the guide's:

Attribute	Where	What it does
#[AsActivity(name:)]	on the contract	prefixes activity names — optional
#[AsActivityMethod(name:)]	on the contract's methods	names an activity
#[AsActivityHandler(contract:)]	on the implementation	registers it — autoconfigured

Three pages carried the same error, and the activities page spelled it out: "a concrete class (often annotated with #[AsActivity] for its name)". Fixed in both languages.

The packages page also promised that "classes carrying #[AsWorkflow] and #[AsActivity] register themselves". That is wrong for both: #[AsWorkflow] is not autoconfigured to date (that is the subject of #255) and #[AsActivity] is not a registration attribute. The page now states the real situation, and points at the durable.workflow tag the guide actually has you write.

B6 — the walkthrough led to no result

The guide stopped at a dispatchNewWorkflowRun() that returns void. Nothing said a consumer had to be running, nor which one — and the only section that mentioned workers was conditioned on Temporal, hence absent from the path the guide prescribes by default.

A step 5 now says it, with the command:

php bin/console messenger:consume durable_workflows durable_activities

Those two names are the transports the reader has just declared in their own messenger.yaml — which is why no document can hand you this command without that file existing first, and why one looks for the missing piece everywhere except in one's own configuration.

The two profiles the guide was mixing

This is the substance of B6, and it was written nowhere. The guide prescribed in-memory:// "for tests and local dev", then showed a dispatch from a controller. The two together cannot work:

• One process — tests. An in-memory transport does not outlive its process. Dispatching from a web request to consume in a separate worker is impossible, and so is replay: the journal the worker would need lives in the web process's memory.
• Several processes — local dev and production. Real transports and a durable store. Both, or the worker picks up a queue entry naming a workflow whose journal it cannot see.

The configuration given for the second profile is not invented: event_store.type, workflow_metadata.type and child_workflow.parent_link_store.type do accept dbal, checked in Configuration.php before being written.

Neighbourhood

Step 5 answers #263 ("nothing says a worker must run, nor which queues it consumes") on the documentation side; the issue also asks for a first-class durable:worker command, which remains to be done. The profile distinction states what #259 observes from another angle: routing durable work where a separate worker cannot read it makes the workflow replay inside the request that started it.

Verification

Final check across the six files: no implementation carries #[AsActivity] any more, each carries #[AsActivityHandler], and every remaining #[AsActivity] is on an interface.

---

Addendum — 2026-09-04, after cross-review

B5 was only half closed. The offending attribute is indeed fixed everywhere — that was verified. But the guide had readers tag all of ../src/Workflow/ without an exclude, and placed the activities underneath it, in App\Workflow\Activity. WorkflowPass filters on nothing but a backslash in the class name, WorkflowRegistry::registerClass() calls the loader without a guard, and WorkflowDefinitionLoader:144 throws "must have exactly one #[AsWorkflowMethod], found 0". A reader following the guide to the letter still ended up with a container that would not build — for a different reason, in the paragraph next to the one this branch was rewriting. The repository's own test bench (symfony/config/services.yaml:23-29) already showed the shape that works: the tagged folder holds workflows and nothing else.

The published routing sent FireWorkflowTimersMessage to sync. The timer is then replayed inside the very process that scheduled it. The bench carries that exact line in its base configuration — and overrides it in when@dev, when@prod and when@test, with the reason in a comment: timer wake-ups carry a DelayStamp, sync:// runs them immediately and ignores the delay, so the sample workflows never finish. The guide had copied the line without the override. It now routes to durable_workflows.

activity_contracts named App\Workflow\Activity\OrderActivities, which the guide never creates: cache:warmup died on a ReflectionException before the first workflow. It is GreetingActivities, the contract of the following steps.

The example controller answered 200 to an asynchronous dispatch that had executed nothing. It answers 202.

The "several processes" profile named doctrine.dbal.default_connection without ever having you install either the DBAL bridge or DoctrineBundle. The missing command is there.

Line-by-line parity between the two languages is preserved: the sixteen headings remain on the same line numbers in _index.md and _index.fr.md.

Still open, out of scope: a bench that follows the guide and goes red when it stops working. The repository has the machinery — the "Magento module (it actually boots)" job goes as far as "a workflow runs in it". That is one more job, not an architecture, and it is what would have made this branch a red regression rather than a review finding.