Code-node Content rendering fails: Graph.Views binds CodeOutputCurrency that the loaded MeshWeaver.Mesh.Contract build does not carry #3518

Activity

1. rbuergi commented on Sep 7, 2026

   

   rbuergi

   on Sep 7, 2026

   Contributor

   More actions

   Question 1 answered — and it eliminates the departure hypothesis entirely

   "does MeshWeaver.Mesh.CodeOutputCurrency exist on current main, when was it added, and if it moved, is there a forwarder?"

   Measured on origin/main:

   exists	yes — src/MeshWeaver.Mesh.Contract/CodeOutputCurrency.cs (the enum at :15, CodeOutputCurrencyExtensions at :60)
   added	2026-09-04, 2dc5868b2 ("a code cell that cannot prove it is current no longer claims to be", #3249), refined by e291c8abe and aea4e9e46
   ever moved	no — one add, no deletion of any file defining it

   🚨 So the #2398-style departure-without-a-forwarder variant is excluded, and so is any in-repo move. The type-forwarders gate has nothing to catch here because nothing left. Question 1 is closed.

   And it is present in every sealed set, checked by path against each:

   aa4075832 (7938)   CARRIES it
   1340e351c (7955)   CARRIES it
   6577052de (7962)   CARRIES it   ← the tag's set
   93dd88941 (7964)   CARRIES it
   

   What that leaves — and it is the night's recurring root, not a new one

   The type is in the repo and in every candidate set, so the stale side is the copy the pod loaded: a MeshWeaver.Mesh.Contract.dll predating 2026-09-04, under a MeshWeaver.Graph.Views that binds a type added on it. That is your hypothesis 2 (store-landed generation vs image copy), not hypothesis 1.

   It is also the same shape as tonight's Store outage on both portals (Plugins#1430): content that moved ahead of the framework the instance is actually running. There, package sources were synced from Plugins main's HEAD into portals running s2f22764 and four Store/* types went to compile Error on named symbols their running core did not have. Here it is a view pack rather than node source, and the failure is a TypeLoadException at render rather than a compile error — but the sentence is identical: the thing that landed is newer than the framework loaded under it.

   🚨 #3509 (merged tonight, #3472) does NOT cover this, and it is worth being explicit so nobody assumes it does. That guard is about NodeType assemblies keyed to a framework identity — it refuses a bake whose identity is not the process's own, and adds CompilationStatus.Foreign so a foreign record stops reporting Ok. A module/view-pack assembly bound by the semver floor is a different lane: the floor deliberately permits a module built against a newer platform to load on an older one, which is exactly the permission being exercised here. Related by root cause, not covered by the fix.

   The one check that still discriminates

   Your item 3 is the right one and is the only remaining question: on the affected pod, the boot [ModuleLoad] report plus /proc/1/maps (the #2223 recipe) — which exact copies of MeshWeaver.Mesh.Contract.dll and MeshWeaver.Graph.Views.dll loaded, their MVIDs, image-vs-store provenance, and the pod's image tag against the rest of the ReplicaSet. That needs cluster access; I have none and did not attempt it.

   🚨 A correction to my own first answer, recorded because it nearly went out wrong

   My first pass reported "none of the four sealed sets carry it" — a false negative, and on a production issue it would have sent someone hunting a phantom regression. Cause: zsh applied a history modifier to the rev-spec. "$s:src/..." begins :s, which zsh reads as the substitute modifier, so git received a mangled rev-spec and answered "not found" about a file that exists. Writing the path through a second variable ("$s:$p") avoids it.

   Absence of a match is not absence of the subject — which is the thing this whole class of issue keeps being about, including in the tooling used to investigate it.
2. rbuergi commented on Sep 7, 2026

   

   rbuergi

   on Sep 7, 2026

   Contributor

   More actions

   Closing as FIXED — same root cause as #3538, confirmed before closing rather than filed as a duplicate

   Verified 2026-09-07T12:25Z against origin/main (fbf9e9be1). The merge queue does not fire
   Closes links, so this is measurement.

   Merged: #3552, merge commit 3ab9dbdcd.

   Why this is the same defect, not merely a similar one

   Three identities, not a resemblance:

   	this issue	#3538
   missing type	MeshWeaver.Mesh.CodeOutputCurrency	same
   consuming assembly	MeshWeaver.Graph.Views (CodeViews.BuildContent)	same, as DefaultViews' module
   deployment / window	memex-cloud, 2026-09-07 03:33–03:35Z	memex-cloud, ~06:00Z, core e36f04c71 (09-03)
   what permitted it	the module lane's declared minMeshVersion floor	minMeshVersion: 3.0.0-rc8, satisfied by 3.0.0-rc9.ci.7693

   The comment above already eliminated the two competing hypotheses by measurement:
   CodeOutputCurrency was added on 2026-09-04 (2dc5868b2), never moved and never deleted, and is
   present in all four sealed sets — so the departure/forwarder variant is excluded and the stale side
   is the copy the pod loaded. That is the semver-floor lane permitting a module built against a newer
   platform to load on an older one, which is exactly #3538's sentence.

   Why closing it as fixed (not as a duplicate) is the right call

   The fix removes the render-end symptom at its cause: ModuleLandingService.LandCore now refuses an
   unlinkable module from memory, before a byte touches disk
   (src/MeshWeaver.PluginCatalog/ModuleLandingService.cs:623-624), and MeshBuilder.InstallAssemblies
   refuses it before Assembly.LoadFrom (src/MeshWeaver.Mesh.Contract/MeshBuilder.cs:206). A
   Graph.Views binding a type its running MeshWeaver.Mesh.Contract lacks can no longer be adopted,
   so BuildContent can no longer reach the TypeLoadException. ModulePlatformLinkTest compiles that
   precise shape with Roslyn — same assembly simple name, missing type — and drives the real landing.

   One item deliberately NOT carried forward

   The issue's investigation step 3 — reading the affected pod's [ModuleLoad] report and
   /proc/1/maps for MVIDs and image-vs-store provenance — was never performed and no longer
   discriminates anything: #3538 established the provenance from the repo side, and the symptom cleared
   on memex-cloud at 07:12Z when the platform was rolled to 3.0.0-ci.7981. Re-running it now would
   measure a healthy pod.

   _{Measured 2026-09-07T12:25Z on origin/main fbf9e9be1 with git log --merges --grep,
   git show --stat 3ab9dbdcd, and grep -rn for the probe's call sites.}
3. rbuergi

   closed this as completedon Sep 7, 2026
4. systemorph-com

   reopened this on Sep 17, 2026
5. systemorph-com commented on Sep 17, 2026

   

   systemorph-combot

   on Sep 17, 2026

   Contributor

   More actions

   Reopened — this fault is happening again.

   Still occurring: 33 more since the last update (37 total).

   • Last seen: 2026-09-07 07:14:44Z
   • Pods: memex-portal-deployment-58c859d4cc-b8pfg, memex-portal-deployment-58c859d4cc-gqqg7

   Recent log lines

   2026-09-07 06:51:01Z memex-portal-deployment-58c859d4cc-b8pfg fail: MeshWeaver.Layout.Composition.LayoutAreaHost[0]
         Rendering failed for area Content
         System.TypeLoadException: Could not load type 'MeshWeaver.Mesh.CodeOutputCurrency' from assembly 'MeshWeaver.Mesh.Contract, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null'.
            at MeshWeaver.Graph.CodeViews.BuildContent(LayoutAreaHost host, MeshNode node, ActivityLog lastActivity, Permission permissions, String editorHeight, String viewer)
            at System.Reactive.Linq.ObservableImpl.CombineLatestSink`1.Next(Int32 index)
   2026-09-07 06:51:01Z memex-portal-deployment-58c859d4cc-b8pfg fail: MeshWeaver.Layout.Composition.LayoutAreaHost[0]
         Rendering failed for area Content
         System.TypeLoadException: Could not load type 'MeshWeaver.Mesh.CodeOutputCurrency' from assembly 'MeshWeaver.Mesh.Contract, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null'.
            at MeshWeaver.Graph.CodeViews.BuildContent(LayoutAreaHost host, MeshNode node, ActivityLog lastActivity, Permission permissions, String editorHeight, String viewer)
            at System.Reactive.Linq.ObservableImpl.CombineLatestSink`1.Next(Int32 index)
   2026-09-07 07:14:44Z memex-portal-deployment-58c859d4cc-b8pfg fail: MeshWeaver.Layout.Composition.LayoutAreaHost[0]
         Rendering failed for area Content
         System.TypeLoadException: Could not load type 'MeshWeaver.Mesh.CodeOutputCurrency' from assembly 'MeshWeaver.Mesh.Contract, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null'.
            at MeshWeaver.Graph.CodeViews.BuildContent(LayoutAreaHost host, MeshNode node, ActivityLog lastActivity, Permission permissions, String editorHeight, String viewer)
            at System.Reactive.Linq.ObservableImpl.CombineLatestSink`1.Next(Int32 index)
   
6. rbuergi commented on Sep 17, 2026

   

   rbuergi

   on Sep 17, 2026

   Contributor

   More actions

   Re-closed — the reopen above was on stale evidence (#4577).

   The recurrence bot reopened this at 2026-09-17T07:51:47Z under the headline "this fault is happening again", but the occurrence its own comment cites is OLDER than the close it reverted:

   the bot's Last seen:	the close it reverted
   2026-09-07 07:14:44Z	2026-09-07T12:31:55Z

   So the counter moved, not the clock — the fault's newest occurrence predates the close, which is the one thing "still happening" has to mean. Root cause and fix: LogIncidentFiler.Reopen reopened on the sole condition that the issue was closed, while the comment-debt clock pays a final count for incidents whose fault has stopped (the fix, Systemorph/MeshWeaver.Plugins#2014, is written but NOT yet merged — it makes a reopen require incident.LastSeen > issue.ClosedAt).

   This restores the close exactly as it stood; nothing is asserted about the defect itself. If the fault happens again, the next occurrence postdates this close and reopens the issue on evidence that means what it says.

   _{One of 53 issues whose reopen was measured stale (129 bot reopens on 2026-09-17, 125 of them inside the 07:51-07:53Z sweep; 76 postdate their close and were left open). Measured and re-closed 2026-09-17 by Claude Opus 5.}
7. rbuergi

   closed this as completedon Sep 17, 2026
8. rbuergi commented on Sep 17, 2026

   

   rbuergi

   on Sep 17, 2026

   Contributor

   More actions

   Adding what the stale-reopen re-close deliberately did not assert: the defect itself is fixed, and the fix is in the image both portals are running.

   • The missing type exists on main: MeshWeaver.Mesh.CodeOutputCurrency at src/MeshWeaver.Mesh.Contract/CodeOutputCurrency.cs (enum + CodeOutputCurrencyExtensions), read on origin/main = 0ec37cf2 today. The TypeLoadException was cross-build skew, not a removed member.
   • The fix is core PR fix: a module is adopted on what this platform can LOAD, not on a version string (#3538, #3518) #3552 — "a module is adopted on what this platform can LOAD, not on a version string (A running portal adopts a module built against a newer platform and every render of it throws TypeLoadException — memex-cloud (core 09-03) took DefaultViews' Graph.Views (needs 09-04 CodeOutputCurrency): every code cell dead, Store/Plugin in compile Error #3538, Code-node Content rendering fails: Graph.Views binds CodeOutputCurrency that the loaded MeshWeaver.Mesh.Contract build does not carry #3518)", merged 2026-09-07T08:39:20Z as 3ab9dbdcd880.
   • It is live on both portals: compare 3ab9dbdcd880...c84c6c05… (the image memex.meshweaver.cloud serves, re-read today via /api/version) → behind_by = 0; same for afde4eab… on memex.systemorph.com.

   And the reopen's own Last seen: 2026-09-07 07:14:44Z is 85 minutes before that fix merged and 5 h 17 m before the close it reverted — so it is evidence from before the fix, not evidence against it.