feat: content-versioned preview ids for local scene development - #1529
Draft
dalkia wants to merge 1 commit into
Draft
feat: content-versioned preview ids for local scene development#1529dalkia wants to merge 1 commit into
dalkia wants to merge 1 commit into
Conversation
In preview, content ids are derived from the file's absolute path only, so a client cannot tell from the id whether a file changed — explorers must drop their caches wholesale on every scene reload to pick up edits. Embed the file's mtime in the id (NUL-separated so it decodes unambiguously: paths cannot contain NUL bytes), making every URL and client cache key derived from it self-invalidating: an edited file gets a new id, unchanged files keep warm caches. The project directory's own id (the scene/entity id) stays path-only so scene identity is stable across edits, and the decoder accepts both plain and versioned ids. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
dalkia
added a commit
to decentraland/unity-explorer
that referenced
this pull request
Aug 6, 2026
…oned ids New sdk-commands embed each file's mtime in its preview content id (NUL-separated from the path), so an edited file gets a new id and every cache key derived from it self-invalidates: the wholesale UnloadCache + UnloadUnusedAssets on reload becomes unnecessary and caches stay warm. Detect the capability from the definition the reload already holds: a NUL byte in a decoded content id is unforgeable by accident (file paths and hostnames cannot contain one), and any doubt — legacy path-only ids, non-b64 ids, malformed base64 — falls back to the full drain, preserving today's behavior against older toolchains byte-for-byte. Toolchain counterpart: decentraland/js-sdk-toolchain#1529 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4 tasks
Contributor
Test this pull request
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR change?
In preview (
dcl start/ Creator Hub), a file's content id is derived from its absolute path only (b64-<base64(path-machineId)>). The id never changes when the file changes, so an explorer cannot tell from the content map whether anything is stale — its only correct option is to drop its caches wholesale on every scene reload and re-download/re-process the entire scene, even for a one-file edit.This PR embeds the file's mtime into the preview id:
Why
Explorer-side scene reload currently spends most of its time re-downloading and re-parsing unchanged assets because of the forced cache drain. With versioned ids the explorer can skip the drain entirely and only re-fetch what actually changed (unity-explorer counterpart: decentraland/unity-explorer#9819). Old explorers are unaffected: they treat ids as opaque strings and keep draining as before.
Notes / follow-ups
.gltf/.glbwith external textures keeps its own id when only a texture changes; a client that caches the composed model must still handle that dependency (or a follow-up could fold dependency mtimes into the model's id). GLBs with embedded textures — the common export — are fully covered.b64HashingFunction(workingDirectory)), which is unaffected.Test it
🤖 Generated with Claude Code