Repository navigation
Activity tracking aborts with no snapshot hydration for rsalzmann/_UserActivity node (recurrence of #1174 pattern) #5109
Description
What is failing
The MeshWeaver.Graph.ActivityTracking service could not record a user-activity update for user rsalzmann on path SecureDevelopmentFramework: the _UserActivity node's per-node hub never delivered an initial state to the mirror within the 30s bound, so the update aborted with a BaseStateTimeoutException.
Probable cause
Most likely the same failure mode already tracked in MeshWeaver#1174 (incident 7473a637daf1e169, now superseded by this one): the _UserActivity node was created (or already existed) but its owning hub never produced an initial frame — a silent RLS rejection of the prior CreateNode, a namespace no NodeType claims, the node being deleted between create and update, or a cold MeshDataSource on a still-activating per-node hub. This instance carries the newer, more precise variant of the exception message, which explicitly notes that a subscribe is acked before hydration, so the owner's activation/routing and its initial read are both still in scope.
Confidence: medium on the mechanism (no hydration inside the timeout), low on which of the four enumerated causes — one sample cannot distinguish them.
Impact
Very low: a single occurrence, on one pod, for one user. One activity-tracking event was not recorded; no user-facing feature failed. This is essentially a recurrence of the already-filed broader pattern rather than a new defect.
Where to look
MeshWeaver.Graph.ActivityTracking— the create/update path forrsalzmann/_UserActivity/*nodes and its 30sMeshNodeStreamHandlebase-state bound.- Whether the
_UserActivityNodeTypeclaims thersalzmann/_UserActivitynamespace in thememexpartition, and whether RLS allows the tracking identity to create there. - Existing issue A CreateNodeRequest addressed to the sending hub itself is never answered (nodeops, empty queue, RunLevel=Started) — activity tracking and every downstream read then time out #1174 — consider treating this ticket as a duplicate/data point for that one rather than a separate investigation.
Evidence
| Fingerprint | 4af198895ca188b1 |
| Category | MeshWeaver.Graph.ActivityTracking |
| Severity | Error |
| Exception | System.TimeoutException |
| Namespace | memex |
| Pods | memex-portal-deployment-75b545bbd-nssvp |
| Occurrences | 1 |
| First seen | 2026-09-21 08:16:56Z |
| Last seen | 2026-09-21 08:16:56Z |
| Routing | not determined — no configured route matches the category MeshWeaver.Graph.ActivityTracking. 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-21 08:16:56Z memex-portal-deployment-75b545bbd-nssvp fail: MeshWeaver.Graph.ActivityTracking[0]
Failed to track activity for user=rsalzmann path=SecureDevelopmentFramework
System.TimeoutException: Update aborted: no initial state arrived for 'rsalzmann/_UserActivity/SecureDevelopmentFramework' within 30s. Likely causes — (1) RLS silently rejected the prior CreateNode, (2) the path is misspelled / points at a namespace no NodeType claims, (3) the node was deleted between create and update, or (4) the per-node hub activated but its MeshDataSource didn't load the node from persistence. NO change item at all reached the mirror inside the bound — no snapshot ever hydrated. This does NOT establish that the owner never answered: a fresh subscribe is ACKNOWLEDGED BEFORE hydration, so an owner that acked and then produced no frame (a cold data source, a per-node hub still activating, an initial read that yielded nothing) reads identically here. Both the owner's activation/routing AND its initial read are still in scope.
---> MeshWeaver.Mesh.MeshNodeStreamHandle+BaseStateTimeoutException: NO change item at all reached the mirror inside the bound — no snapshot ever hydrated. This does NOT establish that the owner never answered: a fresh subscribe is ACKNOWLEDGED BEFORE hydration, so an owner that acked and then produced no frame (a cold data source, a per-node hub still activating, an initial read that yielded nothing) reads identically here. Both the owner's activation/routing AND its initial read are still in scope.
--- End of inner exception stack trace ---
Re-addressed by the current identity function: this incident inherited 7473a637daf1e169 (Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.
Opened automatically from Admin/_LogIncident/4af198895ca188b1. Recurrences are folded into this issue rather than opening new ones.
Activity
systemorph commentedon Sep 21, 2026
Still occurring: 1 more since the last update (2 total).
memex-portal-deployment-75b545bbd-nssvpRecent log lines
Re-addressed by the current identity function: this incident inherited
7473a637daf1e169(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.rbuergi commentedon Sep 21, 2026
Closes as duplicate of #5115.
Reason: same defect —
ActivityTrackingwrites a_UserActivitynode and the per-node hub never delivers an initial state to the mirror, so the update aborts withMeshNodeStreamHandle+BaseStateTimeoutExceptionat the 30 s bound. Grouped with #5115 and #5124 as one symptom family (three users, three paths, one shape) rather than by node name.Evidence migrated to #5115: user
rsalzmann, pathSecureDevelopmentFramework; incident7473a637daf1e169. This sample carries the newer, more precise exception text, which states explicitly that a subscribe is acked before hydration — so the owner's activation/routing and its initial read are both still in scope, and an acked subscribe is not evidence of a live mirror. It enumerates four candidate causes (silent RLS rejection of the priorCreateNode; a namespace no NodeType claims; the node deleted between create and update; a coldMeshDataSourceon a still-activating per-node hub) and states that one sample cannot distinguish them.Candidate roots deliberately not closed against: #1174 (a
CreateNodeRequestaddressed to the sending hub itself is never answered) and #1122 (per-node hubDataContextinitialisation times out) both remain open. This ticket named #1174 as the likely root; that is a hypothesis, and folding an undiagnosed symptom family into a diagnosed root would bury whichever one is wrong. #5115 carries the discriminating measurement instead.