Repository navigation
NumberFieldView subscribe to user hub times out — downstream of hub cache unavailability #1195
Description
What is failing
MeshWeaver.Blazor.Components.NumberFieldView fails to load an 'Order' field in area Settings/2/2/2/1/5 for user sglauser. The component issues a SubscribeRequest via hub cache gmIIqhF220CKKxqxgY_J7Q targeting the user's hub, but receives no response within the 60-second timeout and throws System.TimeoutException.
Probable cause (high confidence)
This is not a defect in NumberFieldView itself. The same hub cache (gmIIqhF220CKKxqxgY_J7Q) and the same user (sglauser) appear in the ThreadChatView timeout incident (issue #1175) at nearly the same timestamps (22:42 and 23:57 UTC on 2026-08-10, same pod kmwvr). The hub cache cannot deliver SubscribeRequest messages to the target hub for that user. The root cause is the broader hub-cache/subscribe-routing failure already tracked in issue #1186 (MessageHubGrain activation times out — partition has no claiming query provider).
Evidence chain:
- Both this incident and ThreadChatView times out subscribing to ThreadComposer hub for user session #1175 share the exact hub cache id
gmIIqhF220CKKxqxgY_J7Q - Both hit the same user (
sglauser) on the same pod (kmwvr) at matching timestamps - The
MessageHubGrainincident (MessageHubGrain activation frequently times out during initialization due to unresolvable mesh nodes #1186, 626 occurrences) documents thatSubscribeRequesttimeouts occur when no query provider claims a target hub's partition — this is the same mechanism manifesting in the Blazor UI layer
Impact
Low. 2 occurrences over ~75 minutes on a single pod. Only the sglauser user is affected — the NumberFieldView component for their Order settings area fails to render during that window. The user may have seen a blank or broken field.
Where to look
- The root cause is the hub-cache/query-provider partition routing — see issue MessageHubGrain activation frequently times out during initialization due to unresolvable mesh nodes #1186 for investigation starting point (
MessageHubGrain.OnActivateAsync(), query provider registration) - For this specific symptom path:
MeshWeaver.Blazor.Components.NumberFieldView— the method that subscribes to the user's hub for data. The component itself is likely fine; it's just the caller of the faulty subscribe. - Consider whether
NumberFieldViewshould handle subscribe timeouts more gracefully (show an error state instead of silently failing), but that's a polish concern, not this defect.
Note: This is a downstream symptom of the same root cause as issues #1175 and #1186. Close as duplicate if #1186 addresses the hub-cache routing.
Evidence
| Fingerprint | ec2af2454acf0a37 |
| Category | MeshWeaver.Blazor.Components.NumberFieldView |
| Severity | Error |
| Exception | System.TimeoutException |
| Namespace | memex-cloud |
| Pods | memex-portal-deployment-59479dc7d9-kmwvr |
| Occurrences | 2 |
| First seen | 2026-08-10 22:42:50Z |
| Last seen | 2026-08-10 23:57:02Z |
Recent log lines
2026-08-10 22:42:50Z memex-portal-deployment-59479dc7d9-kmwvr fail: MeshWeaver.Blazor.Components.NumberFieldView[0]
Loading 'Order' in area 'Settings/2/2/2/1/5' in Area Settings/2/2/2/1/5
System.TimeoutException: No response received in hub cache/gmIIqhF220CKKxqxgY_J7Q within 00:01:00 for request SubscribeRequest (id=ooQ-jOpunky2lqj9_WhNMw) → target sglauser. The request may have been undeliverable or the target hub was not found.
2026-08-10 23:57:02Z memex-portal-deployment-59479dc7d9-kmwvr fail: MeshWeaver.Blazor.Components.NumberFieldView[0]
Loading 'Order' in area 'Settings/2/2/2/1/5' in Area Settings/2/2/2/1/5
System.TimeoutException: No response received in hub cache/gmIIqhF220CKKxqxgY_J7Q within 00:01:00 for request SubscribeRequest (id=kxr9_P2kXE-AWL7Z4RSTnQ) → target sglauser. The request may have been undeliverable or the target hub was not found.
Opened automatically from Admin/_LogIncident/ec2af2454acf0a37. Recurrences are folded into this issue rather than opening new ones.
Activity
rosalie1984 commentedon Aug 11, 2026
The "user session had ended / severity Low / one user affected" scoping in this triage looks wrong — the same hub cache
gmIIqhF220CKKxqxgY_J7Qis poisoning ordinary content paths for every reader, not justsglauser's Settings fields.Live on the same portal at 2026-08-11 07:44–07:56Z (image
ci.2926):DataModeling/Formatting,DataModeling/Validation,DataModeling/17-AttributeToolboxandrsalzmann/GemschiGameall fail their point read through that cache, while children listings, search,Admin/PlatformVersionandDoc/Architectureare fine and/healthzis 200. The nodes demonstrably exist.And it does not heal: three reads of the same path ~11 min apart replayed the byte-identical request id
3kjIJ9lXPUCqPU5Zkgmhjw, so no freshSubscribeRequestis ever issued after the first timeout.NumberFieldView/TextFieldVieware the messenger, not the defect.Root-cause analysis (terminally-faulted
ReplaySubjectentry + theReprobinglatch that can never be cleared once set spuriously) is in #1202 — suggest tracking there and closing this as a downstream symptom.systemorph-com commentedon Sep 17, 2026
Reopened — this fault is happening again.
Still occurring: 5 more since the last update (7 total).
memex-portal-deployment-59479dc7d9-kmwvr,memex-portal-deployment-686bdb74cb-vj9xlRecent log lines
rbuergi commentedon Sep 17, 2026
Re-closed — the reopen above was on stale evidence (#4577).
The recurrence bot reopened this at
2026-09-17T07:52:46Zunder the headline "this fault is happening again", but the occurrence its own comment cites is OLDER than the close it reverted:Last seen:2026-08-11 12:11:31Z2026-08-12T06:58:07ZSo the counter moved, not the clock — the fault's newest occurrence predates the close, which is the one thing "still happening" has to mean. Root cause and fix:
LogIncidentFiler.Reopenreopened on the sole condition that the issue was closed, while the comment-debt clock pays a final count for incidents whose fault has stopped (the fix, Systemorph/MeshWeaver.Plugins#2014, is written but NOT yet merged — it makes a reopen requireincident.LastSeen > issue.ClosedAt).This restores the close exactly as it stood; nothing is asserted about the defect itself. If the fault happens again, the next occurrence postdates this close and reopens the issue on evidence that means what it says.
One of 53 issues whose reopen was measured stale (129 bot reopens on 2026-09-17, 125 of them inside the 07:51-07:53Z sweep; 76 postdate their close and were left open). Measured and re-closed 2026-09-17 by Claude Opus 5.