Found while investigating #3590446. The per-path entity-reference cycle guard in `Browser::normalizeRecursive()` resolves against the **root** entity at every depth, so it misses any cycle that runs across two distinct entities - including the exact example its own comment advertises. ## The mechanism `normalizeRecursive()` recurses at line 808 as ```php $nestedData = $this->normalizeRecursive($currentTokenPath, $subType, $data, $depth + 1, $childVisited); ``` passing `$data` **unchanged**. `resolveReferencedEntity()` at line 966 then does `$source = reset($data)`, while `$fieldName` is the last segment of the *current* path. So at every depth the guard asks the root entity for a field named after a nested sub-token. For a self-reference (`employer_id -> employer_id`, the #3590324 shape) the root and the referenced entity are the same object, so this happens to give the right answer. For a chain across two distinct entities it does not. ## Reproduction `tests/src/Unit/Token/BrowserEntityChainCycleGuardTest.php` on the issue fork builds `contact:1 --(ref_profile)--> profile:2 --(ref_contact)--> contact:1`, with deliberately different field names so a wrong-entity lookup cannot succeed by coincidence. The entity stubs log which object is asked for which field. Executed against ECA 3.1.6 with PHPUnit 12.5.33, the log is: ``` contact:1::hasField(ref_profile) <- depth 1, correct: the root really is the source here contact:1::hasField(ref_contact) <- depth 2, WRONG ENTITY: the root is asked for profile:2's field contact:1::hasField(ref_profile) <- depth 3 ``` `profile:2::hasField(...)` never appears at all. At depth 2 the root has no `ref_contact` field, so `hasField()` returns FALSE and `resolveReferencedEntity()` returns NULL. `$referenced` being NULL means the `canExpandEntity()` guard at line 800 is skipped entirely - it is never consulted - and the root entity is expanded a second time along one path. ## Which recursion path Only the line-808 one. `normalizeValue()` at line 710 *does* rebind `$data` to `[$entityTypeId => $value]`, so had the chain gone that way, hop 2 would necessarily have logged `profile:2::hasField(ref_contact)`. It did not. Structurally this is forced as well: `normalizeRecursive()` never calls `normalizeValue()`, which is reached only from `normalizedTokenData()` and from its own array/`Token`-property recursion at lines 685 and 693. ## Severity - deliberately not oversold **This is not a repeat of #3590324.** Re-running with the depth budget raised to 20 still terminates at three levels. The reason is accidental: at hop 3 the guard asks the root for `ref_profile`, a field the root genuinely does have, resolves `profile:2`, finds it already in `$visited`, and stops. So the guard does fire, against the wrong entity and one hop late. The blast radius is **one surplus expansion of the root entity per cycle**, not unbounded growth. It is a real correctness defect in the guard, not a memory incident. ## Also wrong: the comment Lines 791-793 advertise `owner -> user_picture -> owner` as a case the guard handles. It does not. That comment is the most likely thing to mislead the next reader and should be corrected with the fix. ## Proposed resolution The obvious change is to rebind `$data` at line 808 to `[$referenced->getEntityTypeId() => $referenced]` when `$referenced` is non-NULL. That is **not** a one-line change: `$data` is also the token replacement context used at line 815, so rebinding alters what every sibling sub-token resolves against. The blast radius of that needs tracing before anyone commits to it. ## Remaining tasks - Trace the line-815 `replaceClear()` consequences of rebinding `$data`. - Implement, keeping the existing self-reference regression coverage green. - Correct the comment at lines 791-793. ## Backport None. `src/Token/Browser.php` does not exist on `3.0.x` or `2.1.x`. --- AI-Generated: Yes (agent formed the hypothesis by reading during #3590446, built a two-entity probe whose stubs log which entity is queried, executed it against an ECA 3.1.6 checkout verified byte-identical in the region under test, confirmed the hypothesis, and corrected its own severity estimate downward after finding the tree stays bounded).