fix(module): stop scanning modules APIScanner can never resolve

[soloturn]

AI-assisted change proposal. Filed by agent driven by @soloturn via GDD.

Summary

• setupSandbox() looped over every registered module and scanned each one's
  class index against the system classloader. That's only ever resolvable for
  the engine module (and, in dev mode, modules explicitly loaded onto the JVM
  classpath) — modules loaded from the application/module path live only in
  their own ModuleClassLoader, so the scan was guaranteed to fail for them.
  It was also pointless even on success: JavaModuleClassLoader#loadClass
  only consults this permission set for classes from a non-module
  classloader, so it never gated module-to-module API access anyway.
• Restricted the scan to the engine module plus any dev-mode classpath
  modules, eliminating the routine ClassNotFoundException noise at startup
  without changing sandbox behavior for anything that mattered.

Test plan

• gradle :engine:compileJava passes (verified locally)
• Launch the game and confirm APIScanner no longer logs class-not-found
  for modules loaded from modules/ at startup

Related

• See fix(module): log APIScanner class-not-found at info, not warn+stacktrace gestalt#167, which downgrades the resulting log level but
  doesn't address this underlying scan

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 07056be6-f031-4709-94cb-12eee6538864

📥 Commits

Reviewing files that changed from the base of the PR and between 968904f and f9fa125.

📒 Files selected for processing (1)

• engine/src/main/java/org/terasology/engine/core/module/ModuleManager.java

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • Improved sandbox API scanning to include the engine module and only eligible modules loaded from the JVM classpath.
  • Prevented unrelated registered modules from being scanned, improving accuracy and reliability.

Walkthrough

ModuleManager now tracks successfully registered classpath modules and restricts sandbox API scanning to the engine module plus those tracked modules, excluding application-path modules.

Changes

Classpath sandbox scanning

Layer / File(s)	Summary
Track and scan classpath modules engine/src/main/java/org/terasology/engine/core/module/ModuleManager.java	Adds classpath module tracking during registration and uses that set, together with the engine module, for sandbox API scanning.

Estimated code review effort: 2 (Simple) | ~10 minutes

Poem

A rabbit hops through modules bright,
Classpath paths are tracked just right.
The engine scans with careful eyes,
While app-path modules stay outside.
Permissions bloom beneath moonlight.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: preventing API scanning of modules that cannot be resolved by APIScanner.
Description check	✅ Passed	The description directly explains the scanning change, its rationale, expected effect, and test plan.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/apiscanner-scan-scope

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[BenjaminAmos]

@API exposure for non-classpath modules appears to be completely broken. Fortunately, it does not seem like any core modules make significant use of it.