From 61002a0468c45e4e4bd5e0827eaacd38641e6a9e Mon Sep 17 00:00:00 2001 From: PYDuquesnoy Date: Thu, 3 Sep 2026 05:53:06 +0200 Subject: [PATCH] test(vscode): pin the settings shape that actually exists in the wild MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The SKILLS session swept its tree for #187 exposure and found three .vscode/settings.json of one shape, none of which my tests covered: {"objectscript.conn": {"active": true, "server": "workshop-iris", "ns": "HOSPITAL"}, "objectscript.export": {"folder": "src", "atelier": true}} active:true, a server NAME, and no intersystems.servers map at all — because Server Manager keeps the server definition in USER-scope settings, which this binary does not read. That is the commonest real entry, and under 0.17.0's precedence it is now reached at step 4, ahead of the port scan that currently serves those directories. a_named_server_with_no_matching_entry_is_not_configured covers the NEIGHBOURING case: map present, key absent. This shape takes a different sub-expression — intersystems_servers.as_ref() yields None before .get() is ever reached — and two branches that should agree are not evidence that they do. Behaviour was already verified at the wire on the shipped 0.17.0 binary before this test existed: 0 warnings, the scans ran, `✓ Compiled`. The branch simply had no test. Distinguishing mutation control, not just a mutation: making a missing map skip the named path and fall through to direct host/port fails ONLY the new test (13 passed, 1 failed) with "reported a missing password for a server that was never resolved". A mutation on the shared match arm would have killed both tests and proved nothing about coverage; this one isolates the branch. Tests only — no behaviour change, no version bump. #187 stays open for the search-path gap this shape is a symptom of: user-scope settings are still not read. Co-Authored-By: Claude Opus 5 --- .../tests/vscode_config_tests.rs | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/crates/iris-agentic-dev-core/tests/vscode_config_tests.rs b/crates/iris-agentic-dev-core/tests/vscode_config_tests.rs index 31fe397..43081c9 100644 --- a/crates/iris-agentic-dev-core/tests/vscode_config_tests.rs +++ b/crates/iris-agentic-dev-core/tests/vscode_config_tests.rs @@ -278,3 +278,36 @@ fn path_prefix_survives_resolution() { other => panic!("expected Resolved, got {other:?}"), } } + +/// The shape that actually exists in the wild, found by the SKILLS session in three +/// workshop directories: `active: true` and a `server:` name, with NO +/// `intersystems.servers` map at all — because Server Manager keeps the server +/// definition in USER-scope settings, which this binary does not read. +/// +/// `a_named_server_with_no_matching_entry_is_not_configured` covers the neighbouring +/// case (map present, key absent). This one takes a different branch — +/// `intersystems_servers.as_ref()` yields `None` before `.get()` is ever reached — and +/// the two must not be assumed to agree just because they should. +/// +/// It must resolve to NotConfigured so discovery falls THROUGH to the scans. Anything +/// else would make 0.17.0 break every workshop directory: under the new precedence this +/// entry is reached at step 4, ahead of the port scan that currently serves it. +#[test] +fn a_server_name_with_no_servers_map_at_all_is_not_configured() { + let settings = r#"{ + "objectscript.conn": { "active": true, "server": "workshop-iris", "ns": "HOSPITAL" }, + "objectscript.export": { "folder": "src", "atelier": true } + }"#; + match resolve(settings, None) { + VsCodeResolution::NotConfigured => {} + VsCodeResolution::Resolved(conn) => panic!( + "guessed a connection to {} for a server this binary cannot resolve — \ + discovery would stop here instead of falling through to the scans", + conn.base_url + ), + VsCodeResolution::MissingPassword { .. } => panic!( + "reported a missing password for a server that was never resolved — \ + the warning would name a cause that is not the real one" + ), + } +}