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

Node-operations hub never replies to MoveNodeRequest — feedback relocation times out and submissions strand before reaching triage

Open
  • Is something wrong?
#6,107 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend

Research direction

Start at Feedback/Feedback/Source/FeedbackHandover, then trace the MoveNodeRequest handler registered on the node-operations execution hub and its detached observable. The issue proposes adding NoteRequestStage calls to the handler’s terminal arms; inspect those paths and use a recurrence to identify where the reply is lost. Done means the failure stage is recorded and the move request receives its expected response.

Written by the indexing model from the issue text.

Description

bug sev:M

What is failing

The Feedback module's hand-over watcher relocates a submitted feedback into the shared triage inbox by issuing a MoveNodeRequest to the mesh's node-operations execution hub. The hub accepted and routed the request — a handler was entered and exited with state Processed within a millisecond — but no MoveNodeResponse ever arrived, so the caller's request timeout fired and the relocation was abandoned. The submission itself still stands (by design the hand-over never fails a submit), but it is stranded: the redirect at the old address is never created and the destination hub is never woken, so neither the reviewer inbox nor triage will pick it up.

Probable cause

Moderate confidence on the shape, low on the exact spot. The request never left the target hub — the diagnostic confirms delivery, on-target routing, handler enter/exit at Processed within 1 ms, then silence for the full request window. Canonical mesh handlers return Processed() at once and owe their reply from a detached observable, so the detached work behind the move handler either never completed (a hang inside the move pipeline) or terminated inside code that records no stage and dropped the reply. The handler's inner stages are not instrumented, so this evidence cannot say which. The log's own suggested fix is the right first step: call hub.NoteRequestStage(request.Id, …) at the move handler's terminal arms, so the first recurrence names the arm that died.

Impact

One user-filed bug report was lost from the triage pipeline: it never reached the shared inbox and left no redirect at its old address, so it is invisible to both reviewers and triage until moved by hand. The portal's primary paths are unaffected. This is not a one-off: the same log site failed once before (Ops/Logs/memex-1790617664174974296-9d6f4b-lrxh7), so the relocation path has now silently dropped submissions twice. A sibling incident for the same node one minute later (fingerprint 90fffd4762cd3be9, InvalidOperationException: The operation has timed out) is almost certainly the same failure fanned into a second fingerprint — worth merging during triage.

Where to look

Start at Feedback/Feedback/Source/FeedbackHandover (HandOverOnActivation → MoveToInbox): the Feedback side behaved as designed — it waited for durability before moving, issued the request through NodeOperationExecutionHub(), and surfaced the delivery failure to clear its in-flight flag. The defect is on the answering side: the MoveNodeRequest handler registered on the node-operations execution hub, whose detached observable owes the MoveNodeResponse. Instrument that handler's terminal arms with NoteRequestStage and re-run; the next occurrence will name the stuck leg. Related prior art on this family of ordering hazards is quoted in the same file (MeshWeaver#5670 — a move copies its source from storage, which this watcher already works around); the missing-reply case is the next one in that family.

Evidence
Fingerprint 8d943f4d8f656bd8
Category FeedbackHandover
Severity Error
Exception System.TimeoutException
Namespace memex
Pods memex-portal-deployment-76dd69c7fc-xzsdl
Occurrences 1
First seen 2026-10-04 20:14:53Z
Last seen 2026-10-04 20:14:53Z
Routing not determined — no configured route matches the category FeedbackHandover. 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-04 20:14:53Z memex-portal-deployment-76dd69c7fc-xzsdl fail: FeedbackHandover[0]
      [Feedback] relocation or destination wake of rbuergi/Feedback/fb-agentround-instanceaction-compile-20261004 failed; hand-over is not verified
      System.TimeoutException: No response received in hub portal/nodeops--PztfvZ_ckWW2sZqk6eiZg within 00:01:00 for request MoveNodeRequest (id=rCgdW3bWTU2ZsVKDugqHNQ) → target portal/nodeops--PztfvZ_ckWW2sZqk6eiZg. This hub: RunLevel=Started Queue(buffer=0,deferred=0,openGates=0,drainsInFlight=0,draining=False,handledWhileWaiting=81). 🚨 THIS HUB IS ALSO THE TARGET, so the request never left it: there is no routing leg that could have lost it and no reply leg that could have lost the answer, and "the target's own RunLevel and queue" are the numbers printed above. An empty queue here does NOT mean the request was never handled — the canonical mesh handlers return Processed() at once and owe their reply from a DETACHED observable, so a handler that ran and has not yet produced a terminal looks exactly like one that never ran. What is left is: the delivery was refused at this hub's own intake, or a handler took it and the work that owes the reply produced no terminal. The trail below says which. Trail: AWAITING MoveNodeRequest→portal/nodeops--PztfvZ_ckWW2sZqk6eiZg@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+0ms) → POSTED target=portal/nodeops--PztfvZ_ckWW2sZqk6eiZg@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+0ms) → RECEIVED runLevel=Started@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+0ms) → ENQUEUED@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+0ms) → QUEUED queue=main depth=1@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+0ms) → ROUTED onTarget=True state=Submitted@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+1ms) → HANDLER_ENTER@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+1ms) → HANDLER_EXIT state=Processed@portal/nodeops--PztfvZ_ckWW2sZqk6eiZg(+1ms)  ⇒ a handler was entered and no reply, completion or fault has been recorded since — the work that owes the reply is either STILL RUNNING or terminated inside code that records no stage. …[truncated]

Opened automatically from Admin/_LogIncident/8d943f4d8f656bd8. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site a9f440752288feae: 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
3h 59m
Merged PRs (30d)
975

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.