Version
- cocos-cli
0.0.1-alpha.28
- engine
4.0.0-alpha.20
- Node 25.9.0, macOS (darwin)
- Server started via
node cocos-cli/dist/cli.js start-mcp-server --project <project> --port <port>
Summary
When opening a scene that references assets missing from the project's asset DB / library, alpha.28 correctly fails fast — this is a real improvement, because alpha.19 silently tolerated the same broken scene and gave no signal at all. However, the loader error message contains an empty asset name, so the failure is unactionable: the message tells you that a dependency is missing, but not which one.
Repro sketch
- Have a
.scene that references assets (in our case two sub-assets of skeletal-animation imports) which are no longer present in the project's asset DB / library. (Easy synthetic repro: create a scene referencing an imported asset's sub-asset, then delete the source asset + its library entries.)
- Start the MCP server on the project and call
scene-open on that scene (the same should apply to any code path that loads the scene through the asset-db loader).
- The open fails with a missing-dependency loader error.
In our project the scene referenced 2 missing sub-assets (UUIDs of the form xxxxxxxx-…@b47c0). We could only identify them by manually grepping the .scene JSON and cross-checking against library/ — the error itself did not name them.
Expected
The error message includes the missing asset's name and/or full UUID (ideally including the @sub-asset suffix), e.g.:
Failed to load asset "SK_Foo.fbx@b47c0" (uuid: xxxxxxxx-....@b47c0) referenced by scene "my_scene.scene"
Actual
The error message is emitted with an empty string where the asset name should be, e.g. the equivalent of:
Failed to load asset "" ...
No name, no usable identifier — the placeholder for the asset name is blank.
Impact
- Debugging cost is high: identifying the offending references required dumping the scene JSON and diffing every referenced UUID against the asset DB by hand, instead of reading one log line.
- This hits exactly the users the fail-fast change is meant to help: projects migrating from earlier alphas may discover long-silently-broken scenes, and the first thing they see is an error that cannot be acted on.
- Please keep the fail-fast behavior — only the message needs the asset name/UUID filled in.
This report was drafted with AI assistance and manually verified against our project before posting.
Version
0.0.1-alpha.284.0.0-alpha.20node cocos-cli/dist/cli.js start-mcp-server --project <project> --port <port>Summary
When opening a scene that references assets missing from the project's asset DB /
library, alpha.28 correctly fails fast — this is a real improvement, because alpha.19 silently tolerated the same broken scene and gave no signal at all. However, the loader error message contains an empty asset name, so the failure is unactionable: the message tells you that a dependency is missing, but not which one.Repro sketch
.scenethat references assets (in our case two sub-assets of skeletal-animation imports) which are no longer present in the project's asset DB /library. (Easy synthetic repro: create a scene referencing an imported asset's sub-asset, then delete the source asset + its library entries.)scene-openon that scene (the same should apply to any code path that loads the scene through the asset-db loader).In our project the scene referenced 2 missing sub-assets (UUIDs of the form
xxxxxxxx-…@b47c0). We could only identify them by manually grepping the.sceneJSON and cross-checking againstlibrary/— the error itself did not name them.Expected
The error message includes the missing asset's name and/or full UUID (ideally including the
@sub-assetsuffix), e.g.:Actual
The error message is emitted with an empty string where the asset name should be, e.g. the equivalent of:
No name, no usable identifier — the placeholder for the asset name is blank.
Impact
This report was drafted with AI assistance and manually verified against our project before posting.