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

Node move reports "source not found" for Feedback records that still exist, so they never reach the shared Inbox

Closed
  • Is something wrong?
#5,856 53 comments 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
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
api, backend

Research direction

Start with HandleMoveNodeRequest in src/MeshWeaver.Mesh.Contract/MeshExtensions.cs and trace how the source is resolved, which identity is used, and how query timeouts or empty snapshots become "Source node not found." Compare that path with FeedbackHandover.MoveToInbox and HandOverOnActivation in Feedback/Feedback/Source/FeedbackHandover. Reproduce by activating several submitted Feedback nodes together and verify that existing sources do not produce false failures.

Written by the indexing model from the issue text.

Description

bug sev:M
What is failing

The mesh move (MoveNodeRequest → HandleMoveNodeRequest) rejected two moves with "Source node not found". Both moves were issued by the Feedback package's owning-hub watcher (FeedbackHandover.HandOverOnActivation → MoveToInbox), which moves submitted feedback from the user's space into Feedback/_Submissions. Both source nodes exist. Read back after the failure, rbuergi/Feedback/whisper-model-token-in-git and rbuergi/Feedback/pr-reviewer-blanked-head-no-retry-20260928T1048Z are live Feedback/Feedback nodes. They were last modified at 12:10:57Z and 10:48:39Z, so nothing touched them at the time of the move. Neither target (Feedback/_Submissions/fb-048acabb…, fb-434f6327…) exists. So the move handler said a node was missing when it was there.

Probable cause (low confidence)

The evidence does not establish the cause. What it shows:

  • The failure is in the move handler's source lookup, not in the caller. The error is the handler's own. The watcher only acts on a node it has just seen in its own stream.
  • It looks like a burst on hub re-activation. The Feedback NodeType sources (FeedbackHandover, FeedbackSubmitter, …) were rewritten at 12:12:38Z. Five minutes later, within about 200 ms, several rbuergi/Feedback/* hubs ran their move at once. Another sibling, client-a-test-nodetypes-compiled-per-pod-20260928, moved successfully at 12:17:36.89Z; it is now a Redirect.
  • These two are old, already-handed-over records. handedOverAt and issueUrl are both set. NeedsInboxMove deliberately moves such historical records too.
  • Two candidate explanations:
    1. The source lookup in HandleMoveNodeRequest misses under concurrent load, through a query/catalog read that is either transient or eventually consistent. During this triage, partitions:all queries through PostgreSqlPartitionedMeshQuery were timing out, which fits this but does not prove it.
    2. The identity that MoveToInbox opens with AsSystem does not reach the node-operation hub's read, so a read limited by row-level security answers "not found" for another user's partition. Against this: the sibling move succeeded under the same code path.
  • Either way, the handler cannot tell "absent" from "not visible / not answered". A move that refuses on a false "not found" is safe (nothing is deleted), but the error misleads.
Impact

Small: 2 records, one pod, one burst. No data was lost; the sources are intact. Both records were already handed to triage and have GitHub issues, so triage is not affected. The effect is that these records are missing from the reviewers' Feedback/_Submissions Inbox. The watcher clears inFlight on error but only retries when the node stream emits again, so they may stay there until their hub next activates. The general risk is that any move under concurrent activation can fail spuriously.

Where to look
  • HandleMoveNodeRequest in src/MeshWeaver.Mesh.Contract/MeshExtensions.cs (per Moving Nodes). Check how the source is resolved, under which identity, and whether a query timeout or empty snapshot gets reported as "not found".
  • Caller: FeedbackHandover.MoveToInbox / HandOverOnActivation in @/Feedback/Feedback/Source/FeedbackHandover.
  • Repro idea: activate several submitted user-space Feedback nodes at once and watch for MoveNodeResponse.Success == false on sources that exist.

I found no existing incident or issue for this symptom.

Evidence
Fingerprint 6de9ee65a7b6a9c8
Category MeshWeaver.Mesh.Services.IMeshCatalog
Severity Error
Exception System.InvalidOperationException
Namespace memex
Pods memex-portal-deployment-5c476fdbf8-b957n
Occurrences 2
First seen 2026-09-28 12:17:36Z
Last seen 2026-09-28 12:17:36Z
Routing not determined — no configured route matches the category MeshWeaver.Mesh.Services.IMeshCatalog. 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-28 12:17:36Z memex-portal-deployment-5c476fdbf8-b957n fail: MeshWeaver.Mesh.Services.IMeshCatalog[0]
      Move rbuergi/Feedback/whisper-model-token-in-git -> Feedback/_Submissions/fb-048acabb7122b735d7c8dd4c81619d8e failed
      System.InvalidOperationException: Source node not found at path: rbuergi/Feedback/whisper-model-token-in-git
2026-09-28 12:17:36Z memex-portal-deployment-5c476fdbf8-b957n fail: MeshWeaver.Mesh.Services.IMeshCatalog[0]
      Move rbuergi/Feedback/pr-reviewer-blanked-head-no-retry-20260928T1048Z -> Feedback/_Submissions/fb-434f63278bcafa56bfd86b52d5abaf00 failed
      System.InvalidOperationException: Source node not found at path: rbuergi/Feedback/pr-reviewer-blanked-head-no-retry-20260928T1048Z

Opened automatically from Admin/_LogIncident/6de9ee65a7b6a9c8. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 4cb9d0f9b66a5e33: 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 56m
Merged PRs (30d)
971

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.