Repository navigation
TextFieldView hard-fails when the target user's hub is unreachable #1194
Description
What is failing
MeshWeaver.Blazor.Components.TextFieldView logs a TimeoutException when loading data fields (Name, Category) for a user's settings area. The component surfaces the timeout from the underlying hub cache as a logged failure rather than recovering gracefully or showing a degraded UI.
Probable cause
The component issues a SubscribeRequest to the target user's hub (sglauser in this case) via the hub cache layer. The hub cache timed out after 60 seconds with the message "the request may have been undeliverable or the target hub was not found." This suggests the target user grain (sglauser) was not active, not reachable, or did not respond within the timeout window. With only 2 occurrences across a single pod at the same moment, this is almost certainly a transient hub availability issue — the target user's session may have ended or the grain was in a bad state. There is no evidence of a systemic bug in the data path, but the component's error handling is the defect: a transient hub timeout should degrade gracefully (show a loading/error state or retry) rather than surface an unhandled exception.
Confidence: High that the root cause is a transient unreachable hub. Moderate that the component should handle this better — this is inferred from the fact that the exception is logged at fail: level and not swallowed.
Impact
Minimal. 2 occurrences on 1 pod, same second, for one user (sglauser). No ongoing blast radius. If the same pattern occurs during a larger deployment event (restart or scale-down), it could briefly affect many users viewing settings fields at once.
Where to look
MeshWeaver.Blazor.Components.TextFieldView— the component that fires theSubscribeRequestfor the area path and does not handle timeout.- The hub cache subscription code (assembly that produces the "No response received in hub cache" message) — to understand whether the 60-second timeout is configurable and whether retry logic exists at that layer.
Evidence
| Fingerprint | 96ab40bde5b7fbca |
| Category | MeshWeaver.Blazor.Components.TextFieldView |
| Severity | Error |
| Exception | System.TimeoutException |
| Namespace | memex-cloud |
| Pods | memex-portal-deployment-59479dc7d9-kmwvr |
| Occurrences | 4 |
| 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.TextFieldView[0]
Loading 'Name' in area 'Settings/2/2/2/1/1' in Area Settings/2/2/2/1/1
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 22:42:50Z memex-portal-deployment-59479dc7d9-kmwvr fail: MeshWeaver.Blazor.Components.TextFieldView[0]
Loading 'Category' in area 'Settings/2/2/2/1/3' in Area Settings/2/2/2/1/3
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.TextFieldView[0]
Loading 'Name' in area 'Settings/2/2/2/1/1' in Area Settings/2/2/2/1/1
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.
2026-08-10 23:57:02Z memex-portal-deployment-59479dc7d9-kmwvr fail: MeshWeaver.Blazor.Components.TextFieldView[0]
Loading 'Category' in area 'Settings/2/2/2/1/3' in Area Settings/2/2/2/1/3
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/96ab40bde5b7fbca. Recurrences are folded into this issue rather than opening new ones.
Activity
systemorph-com commentedon Sep 17, 2026
Reopened — this fault is happening again.
Still occurring: 10 more since the last update (14 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:36Zunder 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.