What is failing
The node update pipeline (MeshWeaver.Hosting.NodeUpdatePipeline) cannot deserialize the content of the Markdown node Plyona/Konzeptpapier as MarkdownContent: its As<MarkdownContent> conversion throws a JsonException, and the pipeline fails to "recover the value", aborting updates to that node.
Probable cause
Medium-high confidence, by precedent rather than by stack: the node's stored content payload is malformed for the MarkdownContent shape. A previous finding (PearlTechnology/Docs/MarkdownContentShapeFinding) documented the exact same class of breakage: a Markdown node whose content was stored as { "markdown": … } without the $type discriminator fails to deserialize as MarkdownContent and silently misbehaves — and that finding explicitly noted a code fix in the platform repo (tolerant fallback to the legacy markdown key) was still needed. The single occurrence here (the node is on the memex-cloud tenant, so its payload could not be inspected directly) is consistent with the same missing-$type / malformed-payload shape being rejected at update time instead of display time.
Impact
One occurrence, on one node, on one pod — a single failed update for Plyona/Konzeptpapier. Nuisance-level today, but if other legacy-shaped Markdown nodes exist, every edit to them will hit the same wall, and the operator sees only "JsonException" with content and exception details withheld.
Where to look
MeshWeaver.Hosting.NodeUpdatePipeline — the As<MarkdownContent> value-recovery/conversion path. Make deserialization tolerant of legacy markdown-key payloads (fall back to that key when $type is missing), and surface which JSON error occurred (the withheld details make diagnosis from the log alone impossible). Reference: MarkdownContentShapeFinding.
Related prior finding (same defect class, not previously ticketed): PearlTechnology/Docs/MarkdownContentShapeFinding — its recommendation for a renderer/platform fix was never turned into an issue; this ticket is that code path failing again, in the update pipeline.
Evidence
|
|
| Fingerprint |
f2495ad17cd76111 |
| Category |
MeshWeaver.Hosting.NodeUpdatePipeline |
| Severity |
Error |
| Namespace |
memex-cloud |
| Pods |
memex-portal-deployment-589ff8f895-ql4lr |
| Occurrences |
1 |
| First seen |
2026-09-25 20:21:22Z |
| Last seen |
2026-09-25 20:21:22Z |
| Routing |
not determined — no configured route matches the category MeshWeaver.Hosting.NodeUpdatePipeline. This repository is the configured fallback, not a finding about who owns the fault; the category names the LOGGER, which may not be the subject. |
Recent log lines
2026-09-25 20:21:22Z memex-portal-deployment-589ff8f895-ql4lr fail: MeshWeaver.Hosting.NodeUpdatePipeline[0]
As<MarkdownContent> for Plyona/Konzeptpapier could not recover value: JsonException. Content and exception details withheld.
Re-addressed by the current identity function: this incident inherited 253b5feaa9ed755e (Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.
Opened automatically from Admin/_LogIncident/f2495ad17cd76111. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 8d565806fd2d2338: other fingerprints of this site fold in here as comments rather than opening tickets of their own.
What is failing
The node update pipeline (
MeshWeaver.Hosting.NodeUpdatePipeline) cannot deserialize the content of the Markdown nodePlyona/KonzeptpapierasMarkdownContent: itsAs<MarkdownContent>conversion throws aJsonException, and the pipeline fails to "recover the value", aborting updates to that node.Probable cause
Medium-high confidence, by precedent rather than by stack: the node's stored content payload is malformed for the
MarkdownContentshape. A previous finding (PearlTechnology/Docs/MarkdownContentShapeFinding) documented the exact same class of breakage: a Markdown node whose content was stored as{ "markdown": … }without the$typediscriminator fails to deserialize asMarkdownContentand silently misbehaves — and that finding explicitly noted a code fix in the platform repo (tolerant fallback to the legacymarkdownkey) was still needed. The single occurrence here (the node is on the memex-cloud tenant, so its payload could not be inspected directly) is consistent with the same missing-$type/ malformed-payload shape being rejected at update time instead of display time.Impact
One occurrence, on one node, on one pod — a single failed update for
Plyona/Konzeptpapier. Nuisance-level today, but if other legacy-shaped Markdown nodes exist, every edit to them will hit the same wall, and the operator sees only "JsonException" with content and exception details withheld.Where to look
MeshWeaver.Hosting.NodeUpdatePipeline— theAs<MarkdownContent>value-recovery/conversion path. Make deserialization tolerant of legacymarkdown-key payloads (fall back to that key when$typeis missing), and surface which JSON error occurred (the withheld details make diagnosis from the log alone impossible). Reference: MarkdownContentShapeFinding.Related prior finding (same defect class, not previously ticketed):
PearlTechnology/Docs/MarkdownContentShapeFinding— its recommendation for a renderer/platform fix was never turned into an issue; this ticket is that code path failing again, in the update pipeline.Evidence
f2495ad17cd76111MeshWeaver.Hosting.NodeUpdatePipelinememex-cloudmemex-portal-deployment-589ff8f895-ql4lrMeshWeaver.Hosting.NodeUpdatePipeline. This repository is the configured fallback, not a finding about who owns the fault; the category names the LOGGER, which may not be the subject.Recent log lines
Re-addressed by the current identity function: this incident inherited
253b5feaa9ed755e(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.Opened automatically from
Admin/_LogIncident/f2495ad17cd76111. Recurrences are folded into this issue rather than opening new ones.It also stands for the whole log site
8d565806fd2d2338: other fingerprints of this site fold in here as comments rather than opening tickets of their own.