fix(cli): modules come FROM the upstream seed — identity-matched, never the latest index by rbuergi · Pull Request #2851 · Systemorph/MeshWeaver

rbuergi · 2026-08-30T22:23:01Z

Round 4 of the Manufacturing adoption was the closest yet — the seeded upstream installed, [PASS] Manufacturing (158 nodes, 15 types), every Tests area green — and the adoption postcondition caught the last skew:

Prebuilt assembly for Hosting/InstanceAction DECLINED: dependency record mismatch —
  'MeshWeaver.AI' built against mvid:699963b6…, live is mvid:813bec7e…

10 upstream types declined, because I composed module DLLs from the package index (latest, AI@1.2.8) while the sealed publication's types were built against the sealed module mvids. The reusable gate never has this skew: with an upstream seed, compose-sealed-modules.sh takes the modules from the publication, identity-matched.

The fix

The framework identity is asked of the image up front (--print-framework-identity — the gate's own pre-bake step), so the seed fetch moves before stage 1.
With --upstream-seed, --registry-modules resolves from the seed's own bundles (manifest plugin/module.assemblyName, filename fallback) — identity-matched by construction.
A requested package absent from the seed is a refusal naming it, never a silent skip — a module composed from anywhere else carries the wrong mvid and every publication type built against it would be declined.
Only a build with no upstream seed falls back to the index's latest.

Verification, stated honestly

Build clean at -warnaserror; the up-front refusal still exits 6. The compose path's real proof is the next Manufacturing run against the live registry — deliberately not simulated, because a synthetic seed exercising a private method through a scaffold would prove the scaffold, and this evening has been one long lesson in verifications that exercise the wrong thing.

🤖 Generated with Claude Code

…er the latest index Round 4 (Manufacturing#37): the closest yet — the seeded upstream installed, [PASS] Manufacturing (158 nodes, 15 types), every Tests area green — and the adoption postcondition failed: 10 upstream types DECLINED with 'MeshWeaver.AI' built against mvid:699963b6…, live is mvid:813bec7e… because I composed module DLLs from the package index (LATEST: AI@1.2.8) while the sealed publication's types were built against the SEALED module mvids. The reusable gate never has this skew: with an upstream seed, compose-sealed-modules takes the modules FROM the publication. Same here now: - the framework identity is asked of the IMAGE up front (--print-framework-identity — the gate's own pre-bake step), so the seed can be fetched BEFORE stage 1; - with an upstream seed, --registry-modules resolves from the SEED's own bundles (manifest plugin/module.assemblyName, filename fallback) — identity-matched by construction; - a requested package absent from the seed is a REFUSAL naming it, never a silent skip — a module composed from anywhere else would carry the wrong mvid and every publication type built against it would be declined; - only a build with NO upstream seed falls back to the index's latest. Verified locally: build clean -warnaserror; the up-front refusal still exits 6. The compose path's real proof is the next Manufacturing run against the live registry — stated rather than simulated, because a synthetic seed exercising a private method through a scaffold would prove the scaffold. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

This PR updates BuildPluginCommand in the CLI so that, when --upstream-seed is provided, external module DLLs are composed from the upstream seed’s sealed publication bundles (identity-matched) rather than from the registry index’s “latest” packages, preventing MVID mismatches that cause upstream NodeTypes to be declined at install time.

Changes:

Move upstream seed fetching earlier and derive the framework identity from the tester image (--print-framework-identity) before stage 1.
When --upstream-seed is present, resolve --registry-modules by extracting module DLLs from the seed bundles (ComposeModulesFromSeed) instead of downloading from the registry index.
Refuse (fail) if a requested module package is not present in the upstream seed, instead of silently falling back.

Suppressed comments (3)

src/MeshWeaver.Cli/BuildPluginCommand.cs:103

Newly introduced await in src/ for error output conflicts with the repo’s ban on adding async/await under src/ (deadlock / identity-loss risk if reused in turn-based schedulers). Prefer a non-async execution model for this command path, or push the IO behind IIoPool and keep the public surface reactive.

                await error.WriteLineAsync(
                    $"error: could not resolve a framework identity from the image (got: '{line.Trim()}') "
                    + "— cannot address an upstream publication.");

src/MeshWeaver.Cli/BuildPluginCommand.cs:106

New await added under src/ (writing resolved framework identity). Per repo rules this should not introduce additional async boundaries; refactor to a reactive/synchronous boundary to avoid scheduler parking and AsyncLocal identity loss when code is reused in hub-reachable contexts.

            await output.WriteLineAsync($"framework identity: {frameworkIdentity} (from the image)");

src/MeshWeaver.Cli/BuildPluginCommand.cs:109

Newly introduced await FetchUpstreamSeed(...) under src/ adds another async boundary. The repo’s guidance is to avoid Task/await in production code and compose reactively instead (or isolate async IO behind IIoPool).

            var seeded = await FetchUpstreamSeed(
                options.RegistryUrl!, options.RegistryKey!, upstreams, frameworkIdentity, seedDir, ct);
            if (!seeded) return 8;

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

+            var line = await Capture("docker",
+                ["run", "--rm", "--init", "--entrypoint", "/app/mw-plugin-test", pinned,
+                 "--print-framework-identity"], ct);


+            var unpack = Path.Combine(extDir, $"unpack-{plugin}");
+            if (Directory.Exists(unpack)) Directory.Delete(unpack, true);
+            System.IO.Compression.ZipFile.ExtractToDirectory(bundle, unpack);
+            var modulesDir = Path.Combine(unpack, "meshweaver", "modules");


+            var modulesDir = Path.Combine(unpack, "meshweaver", "modules");
+            if (name is not { Length: > 0 })
+            {
+                var dlls = Directory.Exists(modulesDir) ? Directory.GetFiles(modulesDir, "*.dll") : [];
+                if (dlls.Length != 1) { Directory.Delete(unpack, true); continue; }
+                name = Path.GetFileNameWithoutExtension(dlls[0]);
+            }
+            if (!File.Exists(Path.Combine(modulesDir, $"{name}.dll"))) { Directory.Delete(unpack, true); continue; }


github-actions · 2026-08-30T22:30:17Z