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.

ThegetMarking() 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 =newSubject('first_place');$subject2 =newSubject('second_place');$markingStore =newMethodMarkingStore(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();