Cloning was a shallow copy: the new room's scenes kept pointing at the SOURCE
room's blob until someone saved over them. So every clone of a room shared one
object, a clone read as "already has content" while owning none of it, and the
room a player copied stayed load-bearing for their copy indefinitely. Cloning
RecCenter produced rooms whose data blob was literally room_100_v1.dat, which
is visible in the join log.
Each sub-room's bytes are now copied into the clone's own namespace, keyed by
the CLONE's room id so BlobRouter files them under that room's prefix. Sub-room
0 takes the canonical default name, which matters because the details builder
falls back to exactly that name when a room has no recorded blob — writing the
copy there means both the recorded and the fallback path resolve to real
content. Each copy also gets a RoomDataBlobs row so it is tracked like any
other save.
Two cases deliberately do not clear a reference:
- With no object store configured there is nothing to copy, and a blob name is
only a reference; clearing it would throw away the player's edits, which is
strictly worse than the shared reference. That path keeps the old shallow
behaviour, which is also what the existing user-room clone test asserts.
- A source object that is missing or unreadable leaves the clone empty rather
than failing the request. The room and its sub-rooms are already committed by
that point, so a hard failure would strand a half-made room, and an unsaved
source clones to an empty room anyway.
Everywhere else a reference is either replaced by a real copy or cleared — it
is never left pointing into another room.
Reproduces the two-step handshake the client performs — POST thread/withmembers
to create the thread, then GET thread/{id} to open it — on a conversation that
has never carried a message, which is the case that was 404ing.
The request is sent as a form body rather than a query string, matching the
wire ("ids=9741717&messageCount=50"). That detail is load-bearing for routing,
not just fidelity: POST thread/{chatThreadId} also matches the literal path
thread/withmembers, and the content type is what separates them. Posting with
no body makes the two indistinguishable and the request fails as an ambiguous
match across CreateGroup, WithMembersForm and SendMessageForm.
Alexa