State Contamination in Marking Stores due to Class-based Getter Cache

The issue manifests in Marking Store configurations (e.g., MethodMarkingStore), tracing back to a logic flaw in the core Workflow component's state-accessing mechanism.

The getMarking() method caches the state-accessing Getter Closure based solely on the class name (Subject::class).

In a concurrent, multi-subject environment (e.g., Messenger Workers), this leads to state contamination:

A Worker processes Subject 1, successfully transitioning its state from first_place to second_place.

The cached Getter Closure is created or updated, capturing a reference or memory state related to second_place.

When the same Worker processes Subject 2 (a different instance, whose actual state is first_place in the database), the cached Getter is used.

This Getter incorrectly returns the state related to Subject 1's final marking (second_place), despite Subject 2's data being correct.

Consequently, getMarking() reports a marking of ["second_place":1], causing valid transitions from first_place to be incorrectly blocked.

$subject1 = new Subject('first_place');
$subject2 = new Subject('second_place');

$markingStore = new MethodMarkingStore(true);

$marking1 = $markingStore->getMarking($subject1);
$marking2 = $markingStore->getMarking($subject2);

// Expected: ["first_place" => 1]
// Actual: ["first_place" => 1]
$marking1 ->getPlaces();

// Expected: ["second_place" => 1]
// Actual: ["first_place" => 1]
$marking2 ->getPlaces();