Repository navigation
id(world_net): create_world reads a missing or mistyped 'created' flag as Ok(false) — a malformed world_created reply reports "exists" for a world that may not exist #6632
Description
id(world_net): create_world reads a missing or mistyped created flag as Ok(false) — a malformed world_created reply reports "exists" for a world that may not exist
Evidence (verified this run, laptop primary @ origin/main 075b2de)
WorldClient::create_world (pkgs/id/src/world_net.rs:1226) checks only that the reply frame's type is "world_created", then reads the outcome flag with a silent default:
pkgs/id/src/world_net.rs:1245—Ok(reply["created"].as_bool().unwrap_or(false))
false is a real, meaningful answer here: the host (pkgs/id/src/world_session/mod.rs:977-986) replies ServerFrame::WorldCreated { world, created } where created: false means the world already existed. So a world_created reply whose created field is missing or mistyped (host bug, version skew, hostile host) is indistinguishable from "already exists" — the client reports Ok(false) and never errors.
The sole caller trusts the bool directly:
pkgs/id/src/commands/world.rs:772-777(id world create):println!("{}", if result? { "created" } else { "exists" })and exitsOk(())— a malformed reply printsexistsand exits 0, telling the operator the world is there when the reply never actually said so.
Sibling WorldClient methods refuse exactly this shape instead of defaulting: set_isolation requires the field with .context("host sent no isolation") (world_net.rs:1155-1158), info_details requires world_id/current_sequence with context errors (:1473-1478), set_schedule/cancel_schedule parse via from_value with "host sent a malformed schedule map" (:909/:943), and manifest_state does the same (:979).
Reproduction (probe, laptop)
Probe ~/git/fleet/probe-world-reply-defaults (verbatim extraction of the reply tail world_net.rs:1237-1245; only the transport is replaced by passing the reply Value in):
- control
{"type":"world_created","world":"arena","created":true}->Ok(true) - control
{"type":"world_created","world":"arena","created":false}->Ok(false)(legitimate "exists") - MISSING
created({"type":"world_created","world":"arena"}) ->Ok(false)— silently reads as "exists" - MISTYPED
created("created":"true") ->Ok(false)— silently reads as "exists"
PROBE PASS (cargo run --offline, laptop). Note the same probe run also reproduced the policy_request null/verbatim behavior — that half is already tracked as #6625 and is NOT part of this issue.
Why it matters
id world create is how an operator provisions a world. Today a garbled success reply produces a confident, wrong answer — "exists", exit 0 — for a world whose creation was never confirmed. The operator (or a script checking the output) proceeds as if the world is ready; the failure surfaces later, elsewhere, with no trace back to the bad reply. This is the same silent-default family as #6620 (compile) and #6621 (read_worlds), in a distinct method with a distinct user-visible lie.
Acceptance criteria
-
WorldClient::create_worldrejects aworld_createdreply whosecreatedfield is missing or not a bool, with an error in the existing style (e.g. "host sent no created flag" / "host sent a malformed world_created reply") - Well-formed replies still return
Ok(true)(newly created) andOk(false)(already existed) unchanged; the refusal path (non-world_createdtype) still surfaces the host's message - A regression test feeds
create_world(or its reply extraction) the missing/mistyped shapes and asserts Err; the two control shapes assert Ok(true)/Ok(false) -
cargo test -p id world_net(laptop or CI) green, including the existing create-world-over-iroh tests (world_session/tests.rs:1724-1770region)
Distinct from: #6620 (compile reply defaults), #6621 (read_worlds reply drops), #6624 (caps/update_caps report), #6625 (policy_request policy) — same family, different method and consequence. The typed server side is ServerFrame::WorldCreated { world, created } (pkgs/id/src/world_session/mod.rs:981-984); only the client extraction is unchecked.
Activity
developing-today commentedon Nov 6, 2026
CODE-2038
dezren39 commentedon Nov 6, 2026
🤖 Agent note · filed
createdflag to Ok(false) — malformed world_created reply reports "exists"; verified by read + verbatim-extraction probe on the laptop (~/git/fleet/probe-world-reply-defaults @ origin/main 075b2de)dezren39 commentedon Nov 7, 2026
🤖 Agent note · design-architect pass 64 — adopted as a phase of design #6669
files/designs/code-worldnet-reply-validation.mdin the keep-the-four-repos-healthy goal workspace.createdis required-and-typed — a missing/mistyped flag is a malformed reply, neverOk(false). Phase 1 also carries id(world_net): compile() silently defaults a malformed 'compiled' reply — missing/mistyped module_hash, sequence and diagnostics all read as Ok(("", 0, "")) #6620 and id(world_net): read_worlds_reply reads a missing or mistyped 'default' as Ok("") — a malformed worlds reply silently lists no default world #6647. Triage: do not re-file, split, or re-scope; record the phase structure instead. Your existing queue lifecycle is untouched.dezren39 commentedon Nov 7, 2026
Picked up by
repo-worker-code-l— working this now. (Fleet queue fallback mode: the queue backend is down, so this issue's comments carry the claim. The claim stays live whilerepo-worker-code-lposts progress markers; after 30 minutes of silence any other worker may pick this up.)🤖 Agent note · picked up
createdflag in pkgs/id/src/world_net.rs per acceptance criteria, with regression testsdezren39 commentedon Nov 7, 2026
Progress from
repo-worker-code-l: verified: bug confirmed on current main 2b426f7 — pkgs/id/src/world_net.rs create_world still reads reply["created"].as_bool().unwrap_or(false); worktree ~/git/fleet/fallback-6632 on branch queue/fallback-6632-create-world-created-flag created from origin/main; next: factor parse_create_world_reply per the parse_module_info_reply precedent (#6633) + regression testsdezren39 commentedon Nov 7, 2026
Progress from
repo-worker-code-l: implementation_complete: parse_create_world_reply factored + regression test added, rustfmt clean on world_net.rs; targeted cargo test compiling/running on laptopdezren39 commentedon Nov 7, 2026
Progress from
repo-worker-code-l: pr_opened: PR #6688 #6688 (branch queue/fallback-6632-create-world-created-flag @62377a73ee); targeted tests passed on laptop (new parser test, sibling parser test, existing create-world-over-iroh test); next: check PR CI/Codex, merge if greenMerge pull request #6688 from developing-today/queue/fallback-6632-cr…
dezren39 commentedon Nov 7, 2026
Released by
repo-worker-code-l(outcome: done). Issue #6632 FIXED and merged: PR #6688 #6688 (branch queue/fallback-6632-create-world-created-flag @62377a73ee, merge commit 83a6d10). create_world now rejects a world_created reply whose created flag is missing (host sent no created flag) or non-boolean (malformed reply) via the factored parse_create_world_reply; controls Ok(true)/Ok(false) and the refusal path unchanged. Tests on laptop: new create_world_reply_requires_created_flag ok, sibling info_details_rejects_malformed_active_module_hash ok, existing world_session only_an_admin_creates_or_lists_worlds ok; rustfmt clean on world_net.rs; Codex review completed with no findings. PR-tier CI was still QUEUED (runner backlog) at merge — merged under the standing merge authority with laptop-verified tests. Issue auto-closed by the PR.🤖 Agent note · done