Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

CollaborativeMarkdownView read of mkleiner/BusinessPlan2026 ended with the node's delete — read raced the delete by minutes

Open
  • Is something wrong?
#6,767 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
15/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend

Research direction

Start at the Loading document {path} in Area {path} log site in MeshWeaver.Blazor.Components.CollaborativeMarkdownView, then find where MeshWeaver.Mesh.MeshNodeReadEndedWithDeleteException is thrown on the mesh read path. The issue itself says the cause is undecided and it likely duplicates #6074, so first confirm the delete actor and timestamp and whether the failing read was a cold load or a live refresh. Done means the cause is identified and recorded on #6074, not a patch.

Written by the indexing model from the issue text.

Description

bug sev:L

Observed

MeshWeaver.Blazor.Components.CollaborativeMarkdownView failed twice (1 ms apart, one page load's shape) loading the document mkleiner/BusinessPlan2026 through the view area Overview/2/1/2, raising MeshWeaver.Mesh.MeshNodeReadEndedWithDeleteException: No node found at 'mkleiner/BusinessPlan2026': the node was deleted, and this read of it ended with the delete. The read raced the delete: the node — "Businessplan 2026 — Arbeitsstand für Investorentermin 20.10.", a Markdown document — had 9 versions, the last written by mkleiner at 2026-10-14T10:06:22Z, and it no longer resolves; it was deleted in the ~3 minutes before the 10:09:11Z burst. This is the first burst at this log site carrying the dedicated MeshNodeReadEndedWithDeleteException type; the two earlier incidents at the same site raised DeliveryFailureException (#6076) and InvalidOperationException (#6080).

Where and when

Two occurrences on one pod (memex-portal-deployment-567896cdc8-84nqz), both at 2026-10-14T10:09:11Z, ~1 ms apart — consistent with two parallel reads in a single view activation rather than a recurring rate. A session was actively working on this document's content up to the delete: transcript documents under mkleiner/BusinessPlan2026/_Thread/wo-ist-das-… were written at 10:08:53Z and 10:06:26Z, and the document itself was edited at 10:06:17–10:06:22Z (versions 6–9). No other pod, namespace or tenant shows this fingerprint in the window.

Impact

Nuisance-level: one user's view of one just-deleted document failed. The document is gone by its owner's own recent activity; no outage, no data loss indicated by these two lines.

Not established

  • Who or what deleted the node. I found no delete/audit record for mkleiner/BusinessPlan2026; the deletion itself is inferred from the node's version history ending at 10:06:22Z and the path no longer resolving.
  • Whose session issued the failing read — the document owner's own browser (deleting the document in one tab while the view held it open in another) or another client with a persisted Overview/2/1/2 view area. The log line does not carry a session/user identity.
  • Whether the two lines are one activation's parallel reads or two activations — 1 ms apart on one pod points to the former, but the log site does not carry a request id.
  • Whether the exception type change at this site is behavioural or just a re-typed throw: the same "read ended with the delete" text appeared on 2026-10-04 as InvalidOperationException (#6080); whether the mesh read path was changed to throw the dedicated type (and older pods would still raise the old one) is not established.
  • Whether the still-live thread under the deleted path (mkleiner/BusinessPlan2026/_Thread/…, transcripts written at 10:08:53Z) survived the parent delete by design or indicates the delete did not propagate to descendants — I did not determine which.

Candidate causes and the reading that separates them

  1. Owner deleted the document while a session of theirs still had it open. Predicts: the failing session and the delete actor are the same user (mkleiner), and the delete timestamp sits between 10:06:22Z and 10:09:11Z. Separating reading: the delete/audit entry for mkleiner/BusinessPlan2026 (actor + timestamp) against the session identity of the failing read.
  2. A persisted view area (Overview/2/1/2) references the path and a page (re)load resolved it after the delete — the defect class of #6074/#6076/#6080. Predicts: the read originates from a view-area activation rather than a live editor session, and the same area would fail again on every reload until the area is cleared. Separating reading: whether the same area re-fails on subsequent loads of the same client (the incident shows no recurrence after 10:09:11Z, which weakens this variant).
  3. The delete raced an in-flight read/subscription of an open editor — the exception text ("this read of it ended with the delete") names exactly this shape: a read that started before the delete committed. Predicts: failures cluster in the seconds around a delete of an actively-open document, and never at a later cold load. Separating reading: the pod's request log around 10:09:11Z showing whether the read was a cold activation or a live subscription refresh.

Where to look

  • MeshWeaver.Blazor.Components.CollaborativeMarkdownView — the code behind the Loading document {path} in Area {path} log site, the document-loading read of the area's target path.
  • The mesh read path that throws MeshWeaver.Mesh.MeshNodeReadEndedWithDeleteException ("read ended with the delete").
  • The persisted view area Overview/2/1/2 and how it outlives its target — same class as #6074.
  • Concrete case: deleted mkleiner/BusinessPlan2026 (last edit 2026-10-14T10:06:22Z by mkleiner), failing pod memex-portal-deployment-567896cdc8-84nqz at 10:09:11Z.

Already known

Same log site and same symptom class as #6076 and #6080, both folded into root-cause issue #6074 (saved view areas / open sessions referencing deleted nodes). This incident adds two pieces of evidence the earlier tickets did not carry: the read raced a delete of a node that was being edited three minutes earlier (not a long-stale reference), and the site now surfaces the dedicated MeshNodeReadEndedWithDeleteException type. Likely closable as a duplicate of #6074 by a human in seconds, but the race-window evidence is worth attaching there.

Evidence
Fingerprint 0175303306195abf
Category MeshWeaver.Blazor.Components.CollaborativeMarkdownView
Severity Error
Exception MeshWeaver.Mesh.MeshNodeReadEndedWithDeleteException
Namespace memex
Pods memex-portal-deployment-567896cdc8-84nqz
Occurrences 2
First seen 2026-10-14 10:09:11Z
Last seen 2026-10-14 10:09:11Z
Routing not determined — no configured route matches the category MeshWeaver.Blazor.Components.CollaborativeMarkdownView. 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-10-14 10:09:11Z memex-portal-deployment-567896cdc8-84nqz fail: MeshWeaver.Blazor.Components.CollaborativeMarkdownView[0]
      Loading document mkleiner/BusinessPlan2026 in Area Overview/2/1/2
      MeshWeaver.Mesh.MeshNodeReadEndedWithDeleteException: No node found at 'mkleiner/BusinessPlan2026': the node was deleted, and this read of it ended with the delete. Read the path again if it is re-created.
2026-10-14 10:09:11Z memex-portal-deployment-567896cdc8-84nqz fail: MeshWeaver.Blazor.Components.CollaborativeMarkdownView[0]
      Loading document mkleiner/BusinessPlan2026 in Area Overview/2/1/2
      MeshWeaver.Mesh.MeshNodeReadEndedWithDeleteException: No node found at 'mkleiner/BusinessPlan2026': the node was deleted, and this read of it ended with the delete. Read the path again if it is re-created.

Opened automatically from Admin/_LogIncident/0175303306195abf. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 31ea2577b7190a34: other fingerprints of this site fold in here as comments rather than opening tickets of their own.

Dominant language
C#
Stars
12
Forks
5
Avg merge
5h 34m
Merged PRs (30d)
960

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Systemorph/MeshWeaver

All issues in Systemorph/MeshWeaver

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.