What happens
A run's timeline names every activity by its PHP method:
demo.fulfilment.charge_card 0 ms
demo.fulfilment.reserve_stock 3.0 s
Wait for the warehouse to answer (5 min 00 s)
demo.fulfilment.ship_order 0 ms
One row out of four reads like a sentence. That one is a timer.
Why the timer is different
JournalRunHistoryReader::labelOf() prefers a timer's summary:
return $timerNames[$event->timerId()] ?? ('timer ' . $event->timerId());and $timerNames is filled from $event->summary(). Activities fall through to $activityNames, which holds the activity name.
The summary is right there. ActivityOptions::summary is serialised into the very event that opens the action - I read it back out of metadata.activity_options.summary on ActivityScheduled to work around this.
The plugin README already states the rule this breaks:
Action labels prioritise human-readable names and fall back to technical IDs only when
needed.
and then documents the activity chain as ActivityType.name > activityId > generated. ActivityType.name is the technical name.
Ask
One more preference in labelOf() / the $activityNames map:
activity_options.summary > activity name > activityId > generated
With it, the same run reads:
Charge the card 0 ms
Reserve the goods at the warehouse 3.0 s
Wait for the warehouse to answer (5 min 00 s)
Ship the order 0 ms
Two notes
- The README's label mapping table is written in Temporal vocabulary (
ActivityTaskScheduledEventAttributes.activity_type.name). The DBAL journal has no ActivityType, so that table already describes only one of the two backends.
- A summary set on a shared stub labels every activity the same. That is the caller's problem, not the library's - but a line in
activities.md saying the summary becomes the timeline row would make people give each call its own, the way the timer docs already do ("Always pass the summary").
Workaround in use
A decorator on the run catalog that rewrites each action's label from the summary recorded on its opening event. ~50 lines that a two-line change here would delete.
What happens
A run's timeline names every activity by its PHP method:
One row out of four reads like a sentence. That one is a timer.
Why the timer is different
JournalRunHistoryReader::labelOf()prefers a timer's summary:and
$timerNamesis filled from$event->summary(). Activities fall through to$activityNames, which holds the activity name.The summary is right there.
ActivityOptions::summaryis serialised into the very event that opens the action - I read it back out ofmetadata.activity_options.summaryonActivityScheduledto work around this.The plugin README already states the rule this breaks:
and then documents the activity chain as
ActivityType.name>activityId> generated.ActivityType.nameis the technical name.Ask
One more preference in
labelOf()/ the$activityNamesmap:activity_options.summary> activity name >activityId> generatedWith it, the same run reads:
Two notes
ActivityTaskScheduledEventAttributes.activity_type.name). The DBAL journal has noActivityType, so that table already describes only one of the two backends.activities.mdsaying the summary becomes the timeline row would make people give each call its own, the way the timer docs already do ("Always pass the summary").Workaround in use
A decorator on the run catalog that rewrites each action's label from the summary recorded on its opening event. ~50 lines that a two-line change here would delete.