(rsg) Fix stack overflow from ContentNode parentField notification cascade

[jeremy-albinet]

Summary

Fixes recursive SceneGraph observer cascades that can cause stack overflows in ContentNode update loops (issue #904), using a field-level notification dispatcher instead of global recursion guards.

Root Cause

ContentNode parent-field observers can trigger setValue() on other nodes, which can synchronously notify back and form a recursive loop.

Changes

• Field.notifyObservers() now uses a queued, iterative dispatcher.
• Notifications are coalesced per field within a dispatch batch.
• Removed global recursion depth protection in Node.setValue().
• Added regression test:
  • test/brsTypes/ContentNodeRecursion.test.js

Why this approach

• Avoids stack growth from recursive observer chains.
• Keeps notifications deterministic and local to field dispatch logic.
• Avoids node-type-specific/static guards that can hide legitimate notifications.

Validation

• npm test -- test/brsTypes/ContentNodeRecursion.test.js --runInBand
• npm test -- test/brsTypes/Serializer.test.js --runInBand
• npm test -- test/cli/cli.test.js --runInBand -t "SceneGraph Observers Test"

[jeremy-albinet]

A note on the approach: I want to be upfront that the MAX_SETVALUE_DEPTH guard in Node.ts is more of a safety net than a proper fix — it's a magic number that silently drops setValue calls, which is blunt. The ContentNode.ts reentrancy guard is reasonable but uses a static flag that could be overly broad in edge cases.

The cleanest change here is the ArrayGrid.ts one (setValueSilent for item setup), which is correct regardless.

The deeper question is: why doesn't real Roku firmware recurse here? It likely either queues field notifications asynchronously or has built-in reentrancy protection at the observer dispatch level. Matching that behavior would be the proper fix.

I'm happy to rework this if you have a preferred approach — you know the engine internals far better than I do. Feel free to cherry-pick just the parts that make sense.

[lvcabral]

@jeremy-albinet thanks for the PR, I had this recursiveness issue on my backlog to take a look. A similar approach exists in Field to prevent stack overflow. I'm not sure how Roku handles this, as you said, it must have some queue.

Please use npm run prettier:write before submit, to format the source, otherwise the build fails.

I will review and test your code and update my review.

[lvcabral]

@jeremy-albinet do you have simple way to reproduce this issue ? Can you add it on the CLI tests?
Check how it was done in test/cli/resources/observer-app

[jeremy-albinet]

Updated this PR with a cleaner fix and amended commit (a1b4c8a8).

What changed:

• Replaced recursion-guard style handling with field-level queued/coalesced observer dispatch in Field.
• Removed global Node.setValue() depth cap.
• Added a regression test that reproduces cross-node parent-field observer recursion and verifies it no longer crashes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jeremy-albinet]

Pushed the CLI repro tests you asked for.

Two test apps (same pattern as observer-app): one with mass duplicate observers, one with observer stacking inside callbacks — different recursion paths, both overflow without the fix.

Also cleaned up: removed the old unit test, added CHANGELOG entry and JSDoc on the dispatch method.

Happy to adjust anything — JSDoc verbosity, changelog wording, test structure — feel free to push changes directly to my branch too.