ThreadChatView fails to load a chat thread whose hub recycled through four owner activations without settling #6713

Activity

1. systemorph-com

   added

   bugSomething isn't workingSomething isn't working

   sev:MMedium - secondary path broken, or easy workaroundMedium - secondary path broken, or easy workaround

   on Oct 13, 2026
2. systemorph-com commented on Oct 13, 2026

   

   systemorph-comBot

   on Oct 13, 2026

   ContributorAuthor

   More actions

   Folded in — a DIFFERENT fingerprint from the same log site.

   This issue tracks the log site 0b17bab61a7b3664 (MeshWeaver.Blazor.Chat.ThreadChatView), and these occurrences belong to it. They carry their own fingerprint — the masking split one site across several — so before this they would have opened a SEPARATE ticket. One log site fanned out into 46 of those, which is why they fold here instead. Nothing is discarded: the distinguishing evidence is below, and splitting this back out is a person's call.

   Folded fingerprint	c267704c6a434497
   Log site	0b17bab61a7b3664
   Category	MeshWeaver.Blazor.Chat.ThreadChatView
   Severity	Error
   Exception	MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException
   Detail	Stream {n}xHXO_1R3U2WsOY5CmkfQw: giving up on owner {path} — {n} DISTINCT owner activations have refused this stream (budget {n}). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.
   Namespace	memex-cloud
   Pods	memex-portal-deployment-54856649cb-54lxb
   Occurrences	1
   First seen	2026-10-13 20:01:58Z
   Last seen	2026-10-13 20:01:58Z
   Already folded here	1 fingerprint(s)
   Incident	Admin/_LogIncident/c267704c6a434497
   Triage called it	ThreadChatView thread load fails: sync stream owner (phuong thread hub) recycled through 4 activations without answering

   What triage wrote about this fingerprint

   Observed

   MeshWeaver.Blazor.Chat.ThreadChatView failed to load the chat thread view for area Thread/1 (path /data/"thread"): the underlying data stream (id 4xHXO_1R3U2WsOY5CmkfQw) terminated with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException, naming the owner address phuong/_Thread/where-do-i-add-materials-to-build-our-di-e79aaebbd6b6366796a0. By the exception's own account, 4 DISTINCT owner activations of that address refused the stream against the protocol's budget of 3: the address was recycling in a loop rather than settling, each successor activation dying before it could answer the stream. The stream ends with this error so its readers can re-read; the exception states plainly that the defect is at whatever is requesting the recycles, not at the stream.

   ThreadChatView is the log site that observed the failure while catching the load — the refusal itself is the serialization/stream layer's terminal answer once the owner-activation budget is spent.

   Where and when

   One occurrence, one pod, on the memex-cloud namespace. The refused owner is a personal thread of user phuong — a single owner address, not a fan-out across many nodes.

   The same exception shape (4 distinct activations, budget 3) appears in the ops log store in earlier fleet-wide bursts — dozens of different owners at once (Chat, Analysis, MyAi/_Policy, Edu/Lesson, Video/_Activity, rbuergi, …) around 2026-09-26 06:17–06:19Z, and again around 2026-10-07 10:36Z, on other pods. This incident is not one of those bursts: one stream, one owner, no neighbours. Whether the single-owner case shares a cause with the fleet bursts is not established; they are named here because whoever picks this up will find them in the log store and should know they were seen.

   Impact

   One user-visible failure to load one user's thread chat view at that instant. The stream is designed to end with this error so a re-read retries the load, so the impact to the reader is transient if the recycle loop stopped. Whether the thread still loads is not observed.

   Not established

   • What requested the recycles of the owner address. Nothing in this burst names the requester; the exception points at it but does not identify it.
   • Whether the recycling continued past the sample — no later log lines for this address are in the incident.
   • Why each successor activation died — no per-activation log lines are present, only the terminal exception; the incident carries no stack beyond the ThreadChatView log site.
   • Whether the 2026-09-26 / 2026-10-07 fleet bursts share this cause.
   • Whether the load succeeded on retry — no evidence either way.

   Candidate causes and the reading that separates them

   1. A repeat recycler at the owner address — something issuing repeated DisposeRequests to phuong/_Thread/… (a retype, an overlay self-heal, a NodeType recycle cascade that includes the thread, a governed Hosting/InstanceAction Recycle). Each fresh successor is torn down before it can serve the stream. Predicts: [QUIESCE-START] and/or [RecycleCascade] lines naming that thread's address on the same pod in the seconds before the sample. A Logs query for the address settles it in one read — the [QUIESCE-START] line carries the requester and reason (see Hosting/RecycleAction).
   2. The owner activation dying on its own each time it starts — an initialization or compile fault in that thread's hub that kills every successor before it can answer, with the router re-activating after each death. Predicts: repeated startup/compile exception lines for the address in the same window, and a thread that still fails to load afterwards; a read of the thread today discriminates.
   3. A routing/ownership loop at the pod-hub layer — the stream attach repeatedly landing on a non-owner replica that refuses, with the owner migrating per refusal (cf. MeshWeaver#5183, pod-hub refusal and owner migration). Predicts: PodHubNotHereException refusals naming the address in the same window, and the same stream attaching cleanly once placement settles.

   The first reading to take is the pod's log around the sample instant, filtered on the owner address: it separates all three at once.

   Where to look

   • MeshWeaver.Blazor.Chat.ThreadChatView — the load-failure catch that logged this.
   • MeshWeaver.Data.Serialization — SyncStreamOwnerRefusedException and the owner-refusal budget that raises it (the distinct-activation accounting against budget 3).
   • The owner address phuong/_Thread/where-do-i-add-materials-to-build-our-di-e79aaebbd6b6366796a0 — its hub lifecycle in the window.
   • Core Doc/Architecture/StaleStateUntilRecycle (a hub serves until a DisposeRequest reaches it) and Hosting/RecycleAction (what a governed recycle records, and what [QUIESCE-START] carries).

   Severity note: filed sev:M on the numbers — one occurrence, one pod, one owner, and a load that is designed to retry on re-read. The failure class is user-visible and the underlying recycle loop is unexplained; if the address still recycles or the pattern repeats, a human should re-rule it.

   Still occurring: 1 more since the last update (1 total).

   • Last seen: 2026-10-13 20:01:58Z
   • Pods: memex-portal-deployment-54856649cb-54lxb

   Recent log lines

   2026-10-13 20:01:58Z memex-portal-deployment-54856649cb-54lxb fail: MeshWeaver.Blazor.Chat.ThreadChatView[0]
         Loading '/data/"thread"' in area 'Thread/1' in Area Thread/1
         MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream 4xHXO_1R3U2WsOY5CmkfQw: giving up on owner phuong/_Thread/where-do-i-add-materials-to-build-our-di-e79aaebbd6b6366796a0 — 4 DISTINCT owner activations have refused this stream (budget 3). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.
   
3. rbuergi commented on Oct 14, 2026

   

   rbuergi

   on Oct 14, 2026

   Contributor

   More actions

   This is a duplicate of #6729, which is the anchor for the whole SyncStreamOwnerRefusedException family. The fix is in #6756.

   The root cause was the subscriber's own host stopping, not an owner recycle loop. The pod logged Application is shutting down... in the same second as this burst. Its router answered each re-ask with an untagged ShuttingDown refusal (Host is shutting down, cannot route to …), and the sync stream counted each of those as a "distinct owner activation". The fix rides out such routing-layer refusals on the paced time axis, and their give-up names the route instead of an owner.

   Closing as a duplicate. Verification follows on #6729.
4. rbuergi

   closed this as not plannedon Oct 14, 2026
5. systemorph-com commented on Oct 14, 2026

   

   systemorph-comBot

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Folded in — a DIFFERENT fingerprint from the same log site.

   This issue tracks the log site 0b17bab61a7b3664 (MeshWeaver.Blazor.Chat.ThreadChatView), and these occurrences belong to it. They carry their own fingerprint — the masking split one site across several — so before this they would have opened a SEPARATE ticket. One log site fanned out into 46 of those, which is why they fold here instead. Nothing is discarded: the distinguishing evidence is below, and splitting this back out is a person's call.

   Folded fingerprint	0cf50d9d7d625b31
   Log site	0b17bab61a7b3664
   Category	MeshWeaver.Blazor.Chat.ThreadChatView
   Severity	Error
   Exception	MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException
   Detail	Stream Qlv5xA9kB0WbKiLVHT_zDA: giving up on owner sglauser — {n} DISTINCT owner activations have refused this stream (budget {n}). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.
   Namespace	memex-cloud
   Pods	memex-portal-deployment-6bd97645d4-fwns9
   Occurrences	1
   First seen	2026-10-14 07:26:58Z
   Last seen	2026-10-14 07:26:58Z
   Already folded here	2 fingerprint(s)
   Incident	Admin/_LogIncident/0cf50d9d7d625b31

   What triage wrote about this fingerprint

   Observed

   The composer's context-resolution step in ThreadChatView (log site MeshWeaver.Blazor.Chat.ThreadChatView, message Resolving the composer's context in Area Composer) failed with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: its backing sync stream Qlv5xA9kB0WbKiLVHT_zDA, owned by the hub at address sglauser, terminated after 4 DISTINCT owner activations refused the stream (budget 3). The exception's own text states the address "is recycling in a LOOP, not settling: each successor dies before it can answer", that the stream is deliberately ended so its readers can re-read, and that the mechanism at issue is whatever requests the recycles — not the stream layer and not this view.

   This is the third distinct exception flavor to surface at this exact log-site family through the same gap that the #5372 fix round already recorded as its residual: ComposerAccess.ObserveContextChip (added by MeshWeaver.Plugins#2676) has no error arm, so anything but a clean permission answer reaches SurfaceError — there UnauthorizedAccessException (#5372, and the deleted-context DeliveryFailureException, #6081), here SyncStreamOwnerRefusedException. Not a duplicate of either: the refusal of the owner activation loop is a different mechanism, and those tickets' not-found verdicts are not what this sample carries.

   Where and when

   One occurrence, one pod of the memex-cloud portal, at 2026-10-14T07:26:58Z. It carries more weight than its count of 1: it sits inside a same-second multi-owner burst on the same pod — in the ~60 ms around 07:26:58, at least three other sync streams ended with the identical shape "4 DISTINCT owner activations refused this stream (budget 3)":

   • stream IGyFG7mKpU6xDUJA2KdWdg — owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b (DispatchView, filed as Sync stream of PartnerRe/Esl thread node ended after 4 owner activations refused it — the owner address recycled in a loop #6712)
   • streams nZAlMSigYEeetBkkgrZ0rA and ce8cYSIhL0iIw9VdsrhEXA — owner Admin/Subscriptions/sglauser (HtmlView and Label, filed as Sync-stream owner at Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b recycles in a loop and refuses the stream, failing HtmlView metaHtml render #6723 and Sync stream to a thread hub ends after its owner address recycles four times without settling #6708)

   Several unrelated owner addresses exhausting the same activation budget in the same instant is not the signature of four coincident per-address faults. A larger multi-owner burst of the same shape occurred the previous evening (2026-10-13 ~19:54–20:27 on memex, plus the Admin-owner give-up at 20:45Z filed as #6735), so the mechanism predates today and is not confined to this pod or these owners.

   Impact

   For the affected window the composer's context chip failed for the sglauser session — an intermittent user-visible failure that the stream layer's design bounds (the stream ends so readers re-read on the next render). No data loss indicated. The concern that would re-rule this: while the owner loop ran, the sglauser address was effectively unavailable to anything reading or writing it, and the same systemic trigger hit at least three other owner addresses on the same pod in the same second.

   Not established

   • What requested the recycles of the sglauser hub. The incident carries no stack beyond the log site and no recycle/quiesce log line; nothing read here names a requester, a DisposeRequest reason, an install, a roll or a restart coinciding with 07:26:58Z.
   • Whether each of the four activations died on its own (init fault) or was disposed again by an external recycler — the exception text supports both readings.
   • Whether the loop settled after the fourth refusal, and whether the composer recovered on re-read (predicted by the design, not observed).
   • Whether the same-second siblings share one requester — the coincidence is observed, the common cause is inferred.
   • Whether this fingerprint recurred at this site before today (the same shape appears in fleet logs since late September against other owners, but not at this log site with this owner).

   Candidate causes and the reading that separates them

   1. A systemic recycle trigger on that pod at that instant (roll, restart, convergence or config event recycling many hubs at once — each stream's owner dying before answering). Predicts [QUIESCE-START]/recycle log lines naming several of the burst's owner addresses (sglauser, Admin/Subscriptions/sglauser, Store/Payments/_Rejected/973c…) at ~07:26:58Z, plus a deployment or pod event in that window. Reading: the pod's logs for that second and the deployment events for memex-portal-deployment-6bd97645d4-fwns9.
   2. A per-address fault repeatedly killing the sglauser hub during activation. Predicts error-level activation/init lines for exactly the sglauser address immediately before each refusal, and no recycle lines for the sibling owners unless unrelated. Reading: the pod's hub-init logs for sglauser before 07:26:58Z.
   3. Interaction with the recent ActivationRecycle changes (Systemorph/MeshWeaver PRs ActivationRecycle: recycle a NodeType's live activations on every process #6054 "recycle a NodeType's live activations on every process", fix(graph): defer recycle service resolution until request delivery #6072, EXPRESS: ActivationRecycle resolves nothing heavy on the mesh hub's init turn (Autofac lock-order deadlock reds Plugins main) #6084 — all landed the week of Oct 7). Predicts the give-up loops appearing or sharply increasing only after those PRs rolled out; the late-September historical occurrences argue against it being purely new, but per-site timing has not been checked. Reading: whether the loop-shape occurrences cluster after the rollout date.

   The one reading that separates the first two is the [QUIESCE-START] reason at the sglauser address: the same reason repeated four times names the loop's driver; four different reasons, or none, points elsewhere.

   Related, not duplicates

   • Same burst, sibling sites, already filed: Sync stream of PartnerRe/Esl thread node ended after 4 owner activations refused it — the owner address recycled in a loop #6712 (DispatchView, owner Store/Payments/_Rejected/973c…), Sync-stream owner at Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b recycles in a loop and refuses the stream, failing HtmlView metaHtml render #6723 and Sync stream to a thread hub ends after its owner address recycles four times without settling #6708 (HtmlView/Label, owner Admin/Subscriptions/sglauser). This ticket is the ThreadChatView site with owner sglauser; a human may want to consolidate the burst's systemic cause under one of them.
   • Same log-site family: ThreadChatView fails to load the composer for Anonymous visitors: no Read permission on Anonymous/_Thread/ThreadComposer #5372 (unreadable context — fixed by MeshWeaver.Plugins#2676, whose review predicted exactly this missing error arm) and ThreadChatView context resolution fails unhandled when the composer's bound context node was deleted — no error arm on the context chip #6081 (deleted context node). Both are not-found verdicts at the same step; this sample is an owner-activation refusal, a different mechanism reaching the same unguarded arm.

   Where to look

   • The context-resolution step in ThreadChatView that logs Resolving the composer's context in {area} — src/MeshWeaver.Blazor.Chat/ThreadChatView.razor.cs in Systemorph/MeshWeaver.Plugins (the path the ThreadChatView fails to load the composer for Anonymous visitors: no Read permission on Anonymous/_Thread/ThreadComposer #5372 code search located), and ComposerAccess.ObserveContextChip (MeshWeaver.Plugins#2676).
   • The thrower: the sync-stream owner-refusal logic in MeshWeaver.Data.Serialization — SyncStreamOwnerRefusedException, stream Qlv5xA9kB0WbKiLVHT_zDA, per-stream refusal budget 3.
   • The owner hub at address sglauser: its activation/quiesce logs on pod memex-portal-deployment-6bd97645d4-fwns9 around 2026-10-14T07:26:58Z.
   • The recycle architecture for the automatic recyclers and where their DisposeRequests carry a reason: Stale State Until a Recycle, Retiring an Activation, Hub Disposal Model.

   Left closed — this ticket was closed as NOT PLANNED, which is a decision rather than a claim that the fault stopped. The occurrences below are recorded here; if the decision should change, that is a person's call and not a recurrence's.

   Still occurring: 1 more since the last update (1 total).

   • Last seen: 2026-10-14 07:26:58Z
   • Pods: memex-portal-deployment-6bd97645d4-fwns9

   Recent log lines

   2026-10-14 07:26:58Z memex-portal-deployment-6bd97645d4-fwns9 fail: MeshWeaver.Blazor.Chat.ThreadChatView[0]
         Resolving the composer's context in Area Composer
         MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream Qlv5xA9kB0WbKiLVHT_zDA: giving up on owner sglauser — 4 DISTINCT owner activations have refused this stream (budget 3). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.
   
6. systemorph-com commented on Oct 14, 2026

   

   systemorph-comBot

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Folded in — a DIFFERENT fingerprint from the same log site.

   This issue tracks the log site 0b17bab61a7b3664 (MeshWeaver.Blazor.Chat.ThreadChatView), and these occurrences belong to it. They carry their own fingerprint — the masking split one site across several — so before this they would have opened a SEPARATE ticket. One log site fanned out into 46 of those, which is why they fold here instead. Nothing is discarded: the distinguishing evidence is below, and splitting this back out is a person's call.

   Folded fingerprint	eb1c8d79bc3ac007
   Log site	0b17bab61a7b3664
   Category	MeshWeaver.Blazor.Chat.ThreadChatView
   Severity	Error
   Exception	MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException
   Detail	Stream cGZD9z_L5k6A_x-SD8AvaQ: giving up on owner {path} — {n} DISTINCT owner activations have refused this stream (budget {n}). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.
   Namespace	memex
   Pods	memex-portal-deployment-567896cdc8-84nqz
   Occurrences	1
   First seen	2026-10-14 10:25:48Z
   Last seen	2026-10-14 10:25:48Z
   Already folded here	3 fingerprint(s)
   Incident	Admin/_LogIncident/eb1c8d79bc3ac007
   Triage called it	ThreadChatView's sync stream gives up on a thread owner that recycled four times before any activation could answer (SyncStreamOwnerRefusedException)

   What triage wrote about this fingerprint

   Observed

   ThreadChatView (MeshWeaver.Blazor.Chat) failed while loading the thread chat area for mkleiner/_Thread/wo-ist-jetzt-der-businessplan-fd1de4a8cc8b305e8df8 ("Wo ist jetzt der Businessplan?"): the view's synchronization stream cGZD9z_L5k6A_x-SD8AvaQ ended with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException — four distinct activations of the stream's owner (that thread's hub address) refused the stream within a budget of three, i.e. the owner address recycled in a loop and each successor died before it could answer. The exception's own text states the stream now ends so its readers can re-read, and that the defect is at whatever requests the recycles — the log site is the reporter, not the fault.

   Where and when

   One pod of the memex portal deployment, one occurrence, one owner. The owner is a live, actively-used user thread (an ExecutiveAssistant harness on Provider/OpenRouterEU/z-ai/glm-5.3) whose last activity precedes the failure by about a minute, mid-conversation (a round that had just created and displayed a new page). So the recycles happened while the thread was being written, not after it had gone idle.

   This fingerprint sits in a larger family: the same exception has been ticketed repeatedly at sibling view sites over the past weeks, in bursts that cover many views and many owners in one window (visible in Ops/Logs, e.g. 2026-09-26 and 2026-10-07, and sibling LogIncidents at other view sites within minutes of this one). Those bursts share the "N distinct owner activations, recycling in a loop" shape. Whether this occurrence and that family share one root cause is not established.

   Impact

   The reader of that thread's chat area is handed an error for the stream; the component's design intends readers to re-read, so the failure is intermittent/self-recovering rather than a dead area. In this instance one user's thread view was affected; judged on this incident alone the impact is small, but the family's recurrence across many areas suggests the underlying recycle loop is not rare.

   Not established

   • What requested the four owner recycles. The evidence names the owner and the count, not the recycler.
   • Whether this occurrence and the sibling-burst family share one cause.
   • Whether the thread hub's successors died mid-initialization, mid-teardown, or refused for another reason (permission, compile, store) — the exception does not say why each activation refused.
   • Whether it still occurs for this thread after the re-read.

   Candidate causes and the reading that separates them

   1. A supervision/relaunch loop on the thread's own execution. The thread node carries a supervisionEpisode (dd411faed51744738e8fc2ffa3b2ed2d); the fleet has an open family of owner threads wedging and being relaunched repeatedly (e.g. Systemorph/MeshWeaver.Plugins#2912, feat(build-project): the module-libraries shelf — additional libraries ride with a recorded closure #2914, fix(module-pack): the inspect step needs PROJECT in its env #2919, A stale MainNode from a plugin's .md Skill survives install: the ?? in ParseCanonical is dead code, and the 1b' guard misses the shape #2939, An Editor can now delete the satellite it was allowed to publish — one rule, one answer (#2913) #2945). Predicts: relaunch records under that supervision episode and repeated [QUIESCE-START]/teardown lines naming the thread's hub address in the pod log in the minutes before the failure. Reading: the supervision episode's records and the pod log tail for that thread address.
   2. A parent/package-level recycle cascading onto the thread hub. A recycle of an ancestor address tears down dependent hubs and re-activates them. Predicts: [QUIESCE-START] lines with one shared reason across several addresses on the same pod in the same window, not just the thread's. Reading: pod log quiesce lines for the window, grouped by reason.
   3. The thread's own writes churning its hub (the agent round writing the new page). Predicts: no external recycler — teardown lines only where the round itself touches the thread, with no supervision relaunch. Reading: the same pod log, correlated with the thread node's write history in the window.

   Duplicate check

   No existing issue found for SyncStreamOwnerRefusedException. Related but distinct: #6047 (a held read freezing on owner hand-off — a different failure at the same owner/reader boundary) and the wedged-owner-thread family above (cause, not symptom). A human may judge this a duplicate of whatever issue collects the sibling family.

   Where to look

   • MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException (MeshWeaver.Data) — the owner-activation budget and the give-up that raised this.
   • ThreadChatView (MeshWeaver.Blazor.Chat) — the log site; it reports, it does not cause.
   • The owner thread node and its supervision episode: mkleiner/_Thread/wo-ist-jetzt-der-businessplan-fd1de4a8cc8b305e8df8.
   • Architecture context: /Doc/Architecture/StreamLivenessAndTheHubReference and /Doc/Architecture/SyncHubPopulation for the sync-hub ownership model, and /Doc/Architecture/StaleStateUntilRecycle for the recycle path.

   Left closed — this ticket was closed as NOT PLANNED, which is a decision rather than a claim that the fault stopped. The occurrences below are recorded here; if the decision should change, that is a person's call and not a recurrence's.

   Still occurring: 1 more since the last update (1 total).

   • Last seen: 2026-10-14 10:25:48Z
   • Pods: memex-portal-deployment-567896cdc8-84nqz

   Recent log lines

   2026-10-14 10:25:48Z memex-portal-deployment-567896cdc8-84nqz fail: MeshWeaver.Blazor.Chat.ThreadChatView[0]
         Loading '/data/"thread"' in area 'Thread/1' in Area Thread/1
         MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream cGZD9z_L5k6A_x-SD8AvaQ: giving up on owner mkleiner/_Thread/wo-ist-jetzt-der-businessplan-fd1de4a8cc8b305e8df8 — 4 DISTINCT owner activations have refused this stream (budget 3). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.
   
7. systemorph-com commented on Oct 14, 2026

   

   systemorph-comBot

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Folded in — a DIFFERENT fingerprint from the same log site.

   This issue tracks the log site 0b17bab61a7b3664 (MeshWeaver.Blazor.Chat.ThreadChatView), and these occurrences belong to it. They carry their own fingerprint — the masking split one site across several — so before this they would have opened a SEPARATE ticket. One log site fanned out into 46 of those, which is why they fold here instead. Nothing is discarded: the distinguishing evidence is below, and splitting this back out is a person's call.

   Folded fingerprint	75f1971ec1b1cfed
   Log site	0b17bab61a7b3664
   Category	MeshWeaver.Blazor.Chat.ThreadChatView
   Severity	Error
   Exception	MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException
   Detail	Stream v4a2Hkx_EES8{n}zT1dGLhQ: giving up on owner BusinessPlan2{n} — {n} DISTINCT owner activations have refused this stream (budget {n}). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.
   Namespace	memex
   Pods	memex-portal-deployment-567896cdc8-84nqz
   Occurrences	1
   First seen	2026-10-14 10:25:48Z
   Last seen	2026-10-14 10:25:48Z
   Already folded here	4 fingerprint(s)
   Incident	Admin/_LogIncident/75f1971ec1b1cfed
   Triage called it	Chat composer context resolution in the young Space BusinessPlan2026 faults as its hub recycles through 4 owner activations — sync stream gives up (SyncStreamOwnerRefusedException)

   What triage wrote about this fingerprint

   Observed

   The log site is MeshWeaver.Blazor.Chat.ThreadChatView, resolving the composer's context in area Thread/1 on the memex portal. The resolution faulted with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: sync stream v4a2Hkx_EES808zT1dGLhQ ended after 4 DISTINCT owner activations of the Space BusinessPlan2026 refused it, against the recycle re-arm budget of 3 (JsonSynchronizationStream.MaxRecycleReArms, MeshWeaver.Data). Per the give-up contract (#6602) this is one give-up event that ends the stream so its readers can re-read; ThreadChatView is the reporting site, not the defect site. The exception's own diagnostic names the shape: the address is recycling in a loop rather than settling, and the defect is at whatever requests the recycles.

   Distinctive about this burst against the SyncStreamOwnerRefusedException family: the refusing owner is a Space created this morning (BusinessPlan2026, created 2026-10-14 07:51Z by mkleiner, version 2) — a young node under active construction, not the long-lived subscription/payment/store owners that dominated yesterday's bursts, and this incident sits on the memex instance rather than the memex-cloud pods that carried most of the family. Chat threads referencing the plan were active in the minutes around the event (mkleiner/BusinessPlan2026/_Thread/… at 07:32–07:53; mkleiner/_Thread/wo-ist-jetzt-der-businessplan-… 10:10–10:24, asking where the business plan now lives).

   Where and when

   One pod, one instant, one owner, one stream — a single give-up, not a storm: no second owner refused at the same instant on this instance in the evidence I can read, unlike the two-owner bursts of 2026-10-14 07:26Z on memex-cloud. The owner Space exists and is readable now (I read it), so the address is not a deleted node; whether its hub settled after the give-up was not verified.

   Impact

   One user's chat composer context resolution failed once. By design the stream ends loudly and the reader classifies the fault transient and re-subscribes, so the failure is bounded; whether this view actually recovered was not verified. Judged sev:M from the numbers (single occurrence, one pod, one view), not from the family's urgency — if the family's storm correlation holds, a human re-rules the family upward rather than this ticket alone.

   Not established

   • What requested the four recycles of BusinessPlan2026 — this incident carries no [QUIESCE-START] line, no dispose attribution and no per-activation fault; I found no quiesce/recycle log line naming this address in the window in the readable log store.
   • Whether the four counted activations were four real activations, or a settling teardown charged several times (the activation-identity drift class of Name WHICH recycling failure a ShuttingDown read hit (#2025) #2376 and Sync stream give-up leaves the reader on a frozen last value; one owner teardown is counted as several activations #6602).
   • Whether the Space's hub was failing to initialize on each activation (e.g. a content/NodeType fault inside the young Space), and whether the address settled afterwards or still cycles.
   • Whether a roll, restart or module live-update coincided with the instant on this pod, and whether other owners on this instance refused in the same window.
   • Which chat thread's composer was resolving — the sample names only Thread/1.

   Candidate causes and the reading that separates them

   1. A real recycle loop at the Space's own hub. A young, actively-written Space whose hub activation fails repeatedly (each successor dies before it can answer) fits the exception's own diagnostic. Predicts repeated [QUIESCE-START]/recycle lines naming BusinessPlan2026 in the seconds before 10:25:48Z, each with its requester and reason, and possibly a per-activation fault. Reading: this pod's quiesce/recycle lines filtered to this address, and the Space's hub activation history.
   2. Activation-tag drift. Fewer real activations than the four counted — one settling teardown charged as several, of the class Name WHICH recycling failure a ShuttingDown read hit (#2025) #2376 pinned and Sync stream give-up leaves the reader on a frozen last value; one owner teardown is counted as several activations #6602's test guards. Predicts the four counted tokens resolving to one or two real activations with the address settling normally. Reading: the per-activation tokens (minted by ShutdownNack, MeshWeaver.Messaging.Contract) on the refusals for stream v4a2Hkx_EES808zT1dGLhQ.
   3. The instance-wide recycle-storm family. The family has burst across ~20 view log sites since 2026-10-13; a roll or module live-update on this pod would produce the same single-owner give-up. Predicts quiesce lines naming many different addresses on this pod around the window, plus rollout/deployment records near 10:25Z. Reading: the pod's unfiltered quiesce lines and the deployment records for the instant.

   The [QUIESCE-START] reading separates all three directly: it names who asked for each teardown and why.

   Where to look

   • JsonSynchronizationStream's recycle re-arm latch (MeshWeaver.Data) — the give-up path and its two budgets (MaxRecycleReArms = 3, MaxSameActivationReAsks = 16); the ride-out contract, the two recycling shapes and the activation-tag rules are documented in Riding Out a ShuttingDown Address.
   • The owner Space BusinessPlan2026 — its hub's activation history and what was recycling it in the window; note its content was still being assembled that morning.
   • The sibling family, not established as causes here: the SyncStreamOwnerRefusedException incidents bursting since 2026-10-13 across memex and memex-cloud (yesterday's already filed as Sync stream refuses after a Thread hub's owner activations die in a loop — LayoutStackView header load fails on one memex thread #6711, Thread hub recycles through 4 owner activations without ever answering its portal view stream (SyncStreamOwnerRefusedException) #6706, Sync stream of PartnerRe/Esl thread node ended after 4 owner activations refused it — the owner address recycled in a loop #6712), the fleet-wide give-up investigation Fleet watch stops observing the fleet, freezing every Ops/Status reading as silently stale history #5011, the give-up contract Sync stream give-up leaves the reader on a frozen last value; one owner teardown is counted as several activations #6602 and the activation-tag drift Name WHICH recycling failure a ShuttingDown read hit (#2025) #2376.

   Left closed — this ticket was closed as NOT PLANNED, which is a decision rather than a claim that the fault stopped. The occurrences below are recorded here; if the decision should change, that is a person's call and not a recurrence's.

   Still occurring: 1 more since the last update (1 total).

   • Last seen: 2026-10-14 10:25:48Z
   • Pods: memex-portal-deployment-567896cdc8-84nqz

   Recent log lines

   2026-10-14 10:25:48Z memex-portal-deployment-567896cdc8-84nqz fail: MeshWeaver.Blazor.Chat.ThreadChatView[0]
         Resolving the composer's context in Area Thread/1
         MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream v4a2Hkx_EES808zT1dGLhQ: giving up on owner BusinessPlan2026 — 4 DISTINCT owner activations have refused this stream (budget 3). The address is recycling in a LOOP, not settling: each successor dies before it can answer. The stream now ENDS with this error so its readers can re-read; the fix is at whatever is requesting the recycles, not here.