Owner-recycle loop on Store/Payments/_Rejected payment view kills its sync stream; IconView 'icon'/'iconWidth' loads fail

Observed

The MeshWeaver.Blazor.Components.IconView component rendering area Overview/1/1/1/1/1/1 failed to load its icon and iconWidth properties; both loads surfaced the same MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException for one and the same stream, _qeQIr5atUWnOqtIf2a7Rw. These are two property reads of one underlying stream event, not two independent failures.
Per the exception text, the owner address Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b (namespace memex-cloud) cycled through 4 distinct owner activations that each refused the stream against a budget of 3 — the address was recycling in a loop, each successor dying before it could answer — and the stream was ended with this error so its readers re-read.
The view being rendered is a rejected-payment view under Store/Payments/_Rejected.

Where and when

Single pod, single instant: both samples land in the same second, and the incident shows no spread to other pods or windows. A one-off burst on one portal replica, not a steady rate.

Impact

One portal view — the Overview/1/1/1/1/1/1 view over rejected payment 973c8980476a49cba8b8059e8e91bf4b — lost its live-update stream and its icon properties failed to load. Judged sev:M: a secondary path (icon rendering on one view) broken with an easy recovery path (the stream ends so readers re-read); no evidence of portal-wide or multi-tenant impact, and the counts are far too small to argue otherwise.

Not established

Why the owner activations refused. No application stack frame beyond the exception itself was captured, and the MeshWeaver.Data.Serialization source was not readable in the partitions this triage could search, so the refusal mechanism (activation throwing, activation disposed early, address unresolvable) could not be read from code.
Whether the node still exists. Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b did not resolve from any partition readable here, so whether that address is live, deleted, or tenant-scoped differently is unknown.
Whether it recurred after this instant, and whether other log sites show the same stream or address failing — only this site was fingerprinted in this window.
No prior incident or issue for this component/symptom was found in the incident store; this does not appear to be a duplicate.

Candidate causes and the reading that separates them

The owner activation for that address fails during startup — it throws or is disposed before it can answer, so every successor dies the same way. Predicts: an accompanying error at the owner-activation site naming the same address within the same second on the same pod. Reading: pod logs around the incident instant for activation failures on Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b.
Something is actively requesting recycles of this address — the exception's own text points at "whatever is requesting the recycles". Predicts: repeated recycle/dispose requests targeting that address in the seconds before the give-up. Reading: what issued recycle requests for that address in that window.
The address no longer resolves — the node was deleted or moved while the portal still held the view's stream open, so each successor activation refuses. Predicts: the path does not resolve now, or its version history shows a deletion/restore near the incident time. Reading: resolve Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b in memex-cloud and inspect its version history around the incident timestamp.

Where to look

Reporting site: MeshWeaver.Blazor.Components.IconView — this is only where the dead stream surfaced; the component itself behaved as designed.
Failing mechanism: the stream-ownership/activation protocol behind MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException, for address Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b, stream _qeQIr5atUWnOqtIf2a7Rw, on pod memex-portal-deployment-54856649cb-m2jn9.
Note: the framework source for these types was not found in the readable partitions of this mesh, so no file or method can be named from evidence.

Evidence


Fingerprint	`7a3306f6e11bdc87`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Namespace	`memex-cloud`
Pods	`memex-portal-deployment-54856649cb-m2jn9`
Occurrences	2
First seen	2026-10-13 19:52:18Z
Last seen	2026-10-13 19:52:18Z
Routing	not determined — no configured route matches the category `MeshWeaver.Blazor.Components.IconView`. 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-13 19:52:18Z memex-portal-deployment-54856649cb-m2jn9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'icon' in area 'Overview/1/1/1/1/1/1' in Area Overview/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream _qeQIr5atUWnOqtIf2a7Rw: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.
2026-10-13 19:52:18Z memex-portal-deployment-54856649cb-m2jn9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/1/1/1/1/1/1' in Area Overview/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream _qeQIr5atUWnOqtIf2a7Rw: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.

_{Opened automatically from Admin/_LogIncident/7a3306f6e11bdc87. Recurrences are folded into this issue rather than opening new ones.}
_{It also stands for the whole log site 3d33a3000718df06: other fingerprints of this site fold in here as comments rather than opening tickets of their own.}

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

This issue tracks the log site 3d33a3000718df06 (MeshWeaver.Blazor.Components.IconView), 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	`d248590436c89294`
Log site	`3d33a3000718df06`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Detail	`Stream uv0{n}yPRUkaGh6TCDiRLhA: 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-m2jn9`
Occurrences	2
First seen	2026-10-13 19:52:18Z
Last seen	2026-10-13 19:52:18Z
Already folded here	1 fingerprint(s)
Incident	`Admin/_LogIncident/d248590436c89294`
Triage called it	Owner `Admin/Subscriptions/sglauser` recycled through 4 distinct activations in a loop, spending IconView sync streams' re-arm budget

What triage wrote about this fingerprint

Observed

On the memex-cloud portal pod, IconView loading its 'icon' and 'iconWidth' properties in area Overview/1/1/1/1/1/1 faulted with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: sync stream uv075yPRUkaGh6TCDiRLhA gave up on its owner — the hub at Admin/Subscriptions/sglauser — after 4 DISTINCT owner activations refused the stream against the re-arm budget of 3.

This is the sync stream's give-up path (#6602, JsonSynchronizationStream's recycle re-arm latch): the rider behaved as designed — the stream ENDED so its readers re-read — and the exception's own text names the finding: the owner address was recycling in a LOOP, not settling; each successor dies before it can answer. Per Riding Out a ShuttingDown Address, a rejection from a new activation is a new recycle, so four distinct activations at one address is four recycles — the degenerate loop the budget exists to stop.

Where and when

A single sub-second burst on one pod. Two sibling incidents opened in the same second record the identical give-up on a different, unrelated owner at the same instant: Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b (see Admin/_LogIncident/7a3306f6e11bdc87 and Admin/_LogIncident/04d545c72ffa86f8). So at that moment at least two unrelated addresses were recycling in loops simultaneously on the same pod — the "many owners, many probes" shape the framework's own diagnostic distinguishes from a single wedged hub, and which points at whatever was requesting the recycles, not at the readers.

Impact

Judged from the numbers: a tiny one-pod burst, and the failing component is a portal icon view whose stream ends by design so the reader can re-read. The user-visible effect is at most a transient missing icon in one deep area; the harm is whatever is keeping those owner addresses from settling, which these lines only expose. The give-up itself is the designed loud signal, not the defect.

Not established

The cause. Nothing in the evidence names what requested the recycles or why each successor activation died before it could answer.
Whether the recycle loops continued after the burst window, and whether they recur.
Whether other pods saw the same loops — the evidence covers one pod of this deployment.
Whether the two owner addresses (Admin/Subscriptions/sglauser and Store/Payments/_Rejected/973c…) were recycling for the same reason.
Why an icon/iconWidth read in area Overview/1/1/1/1/1/1 is served by a stream owned by Admin/Subscriptions/sglauser — the relationship between the area and that owner is not visible in the evidence.
No already-open issue covers this fingerprint; the burst shape matches the give-ups seen during rolls and module live-updates, but no roll, restart or publish is confirmed for this window.

Candidate causes and the reading that separates them

A broad recycle driver on the pod recycled many hubs at once and the successors kept dying before answering — the shape of #4866, where every hub bound to a Store/Plugin overlay self-healed at once. Predicts dispose/[QUIESCE-START] lines across many unrelated addresses on this pod inside the same window. Reading: pod logs around the burst instant for [QUIESCE-START] reasons and recycle-request lines — broad vs narrow settles this against 2.
A requestor looping on these specific addresses — e.g. the retype/recycle race of #6034, or a recycle job of the kind enqueued by #6217. Predicts repeated dispose requests at just those two addresses, each carrying a stated reason. Same reading as 1, read narrowly.
Each successor died during its own initialization (a NodeType build or activation failure at that address), the recycles being the response rather than the driver. Predicts hub-init/compile errors for those NodeTypes on the pod and loops persisting well beyond the burst. Reading: init errors at the two owner addresses after the burst instant.
Distinct-activation accounting drift — one teardown counted as several activations (the tag-drift classes of Name WHICH recycling failure a ShuttingDown read hit (#2025) #2376/Sync stream give-up leaves the reader on a frozen last value; one owner teardown is counted as several activations #6602: a NACK or StreamEndedEvent carrying the wrong identity). Predicts the refusal tokens resolve to fewer than 4 distinct activations. Reading: the per-activation tokens carried in the ShuttingDown NACKs on stream uv075yPRUkaGh6TCDiRLhA (minted by ShutdownNack, MeshWeaver.Messaging.Contract).

Where to look

JsonSynchronizationStream's recycle re-arm latch (MeshWeaver.Data) — the give-up path and its two budgets (MaxRecycleReArms = 3, MaxSameActivationReAsks = 16); Riding Out a ShuttingDown Address documents the rider contract and the one-owner/many-owners diagnostic.
Pod logs for dispose requests, [QUIESCE-START] reasons and recycle announcements naming Admin/Subscriptions/sglauser and Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b in the burst window.
Related recycle requestors, not established as causes: Second write racing a retype's hub recycle is refused as Unknown instead of retry-this #6034, Recycle jobs for the Hosting platform's own NodeTypes are enqueued without their declaration seal and refused #6217, Overlay self-heal staleness verdict recycles every Store/Plugin-bound hub at once, discarding 105 deferred requests mid-burst #4866.
Same-instant sibling incidents (same site, other owners): Admin/_LogIncident/7a3306f6e11bdc87, Admin/_LogIncident/04d545c72ffa86f8.

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

Last seen: 2026-10-13 19:52:18Z
Pods: memex-portal-deployment-54856649cb-m2jn9

Recent log lines

2026-10-13 19:52:18Z memex-portal-deployment-54856649cb-m2jn9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'icon' in area 'Overview/1/1/1/1/1/1' in Area Overview/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream uv075yPRUkaGh6TCDiRLhA: giving up on owner Admin/Subscriptions/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.
2026-10-13 19:52:18Z memex-portal-deployment-54856649cb-m2jn9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/1/1/1/1/1/1' in Area Overview/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream uv075yPRUkaGh6TCDiRLhA: giving up on owner Admin/Subscriptions/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.

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

This issue tracks the log site 3d33a3000718df06 (MeshWeaver.Blazor.Components.IconView), 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	`04d545c72ffa86f8`
Log site	`3d33a3000718df06`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Detail	`Stream HO0YVkEcjEmUYQMy_iqSZg: 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-m2jn9`
Occurrences	2
First seen	2026-10-13 19:52:18Z
Last seen	2026-10-13 19:52:18Z
Already folded here	2 fingerprint(s)
Incident	`Admin/_LogIncident/04d545c72ffa86f8`
Triage called it	IconView's sync stream ended after its owner address (Store/Payments/_Rejected payment record) recycled through four activations without settling

What triage wrote about this fingerprint

Observed

A client-side IconView (MeshWeaver.Blazor.Components.IconView) loading the properties icon and iconWidth in area Overview/1/1/1/1/1/1 had its synchronization stream HO0YVkEcjEmUYQMy_iqSZg ended with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: the owner address Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b went through 4 distinct owner activations, each refusing the stream (budget 3) — the address recycling in a loop, each successor dying before it can answer. The exception's own text states the defect is at whatever requests the recycles, not at the stream.

Two corroborating readings off the mesh:

The owner node is absent now: get Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b answers Not found, and Store/Payments lists no descendants.
The log site is the victim, not the defect: the two failures are the same stream ending, reported once per property load. The loop is at the owner address.

Where and when

One burst, one instant (both samples within the same ~50 ms), one pod (memex-portal-deployment-54856649cb-m2jn9, memex-cloud), one stream. What it coincides with, read and not inferred:

Store/_GitSync was last modified at 19:52:40Z — about 22 s after this burst, i.e. a GitHub sync of the Store partition completed immediately afterwards.
A wave of Store/* Release nodes (Catalog, Order, Plugin, Maintenance, Tier, Subscription, Publishing, Provision, Coupon, …) landed at 16:43–16:44Z the same day, three hours earlier.

The same exception text — different stream ids, owners and pods, other log sites — appears throughout Ops/Logs from late September onward (owners including Approvals, FractalStars/_Entitlements, several UWDeepfield types, Hosting/Triage threads), so this looks like one sighting of a recurring fleet-wide pattern. No existing incident covering this log site was found in the mesh.

Impact

One Overview page's two icon properties failed to load, once, on one pod. The stream ends with this error by design so its readers re-read, so the IconView recovers on the next render; no data loss is indicated. The underlying loop is what matters: whatever kept recycling the owner address, it starved the node's readers of a settled owner for the length of the loop.

Not established

What requested the recycles. Nothing on the incident names the requester; the exception points away from itself. This is the open question.
Whether the owner node existed and was deleted inside the window, or failed to resolve on every activation. It is absent now, but its version history could not be read.
Whether other readers of that owner were affected — only this stream id appears.
Whether the pattern still recurs; this incident is the only sighting at this log site.
Whether the IconView area path (Overview/1/1/1/1/1/1) or the rejected-payment record's own lifecycle has any bearing — not read.

Candidate causes, and the reading that separates them

The owner node was deleted or pruned — e.g. by the Store GitSync import that completed ~22 s later — while live client streams still pointed at it. A delete is a change event no mirror can be held to; each re-activation finds no node and refuses. Predicts the node's absence (observed) and a prune of Payments/_Rejected/973c… from the synced tree. Discriminating reading: get_versions on Store/_GitSync for the import that ran at 19:52:40Z, and whether that commit's tree contains the path; a delete change-feed event for the path at ~19:52:18Z would settle it.
A retire-after-init-fault loop on the owner activation — the RetiringAnActivation shape, or one of the four automatic recyclers (WithOverlaySelfHeal, NodeTypeRebindWatcher, …) re-firing on each degraded successor. Predicts repeated [QUIESCE-START] lines at that address in the seconds before the burst. Discriminating reading: the pod's log for QUIESCE-START / Recycle at Store/Payments/_Rejected/973c… — each carries a Reason naming the requester, the single most decisive reading available.
Two unattended writers flapping over the partition — the sync prunes the node, another writer recreates it, the next pass prunes again (the two-writers-of-one-partition family documented in Doc/Architecture/SyncRefContract and ModuleActivationHeadOwnership). Predicts paired GitSync import versions and a second writer's record versions in the same window. Same readings as (1), plus the Store install records.

Where to look

The exception and the stream model: MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException, src/MeshWeaver.Data/Serialization/ (SynchronizationStream.cs); see Doc/Architecture/SyncHubPopulation for the two-sided (client/owner) stream construction.
Who may recycle and what each recycle owes the log: Doc/Architecture/StaleStateUntilRecycle (the four automatic recyclers, the Reason contract on DisposeRequest, ArmStaleAssemblySelfHeal / WithOverlaySelfHeal) and Doc/Architecture/RetiringAnActivation (a hub that retires itself after a transient init fault must fail its gate before it disposes).
The Store partition's writers: Store/_GitSync (version history around 19:52:40Z) and the Store install records.
The fleet-wide pattern: Ops/Logs entries carrying the same "giving up on owner … DISTINCT owner activations" text.

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

Last seen: 2026-10-13 19:52:18Z
Pods: memex-portal-deployment-54856649cb-m2jn9

Recent log lines

2026-10-13 19:52:18Z memex-portal-deployment-54856649cb-m2jn9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'icon' in area 'Overview/1/1/1/1/1/1' in Area Overview/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream HO0YVkEcjEmUYQMy_iqSZg: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.
2026-10-13 19:52:18Z memex-portal-deployment-54856649cb-m2jn9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/1/1/1/1/1/1' in Area Overview/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream HO0YVkEcjEmUYQMy_iqSZg: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.

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

This issue tracks the log site 3d33a3000718df06 (MeshWeaver.Blazor.Components.IconView), 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	`aeb88d4b014483e4`
Log site	`3d33a3000718df06`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Detail	`Stream {n}SFoN8p8{n}CmrYYhEJYi-g: 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-85f6665f88-mzv8m`
Occurrences	2
First seen	2026-10-13 20:22:46Z
Last seen	2026-10-13 20:22:46Z
Already folded here	3 fingerprint(s)
Incident	`Admin/_LogIncident/aeb88d4b014483e4`
Triage called it	Sync stream owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b recycles in a loop, refusing its stream and failing every portal view bound to that node

What triage wrote about this fingerprint

Observed

Portal views rendering the rejected-payment record Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b failed while loading properties (icon, iconWidth here; sibling log sites show title, receivedAt, contentType, headers, body) with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: stream 0SFoN8p830CmrYYhEJYi-g gave up on that owner after 4 distinct owner activations refused it against a budget of 3. The exception's own text states the owner address is recycling in a loop rather than settling — each successor activation dies before it can answer — so the sync stream terminates with this error instead of serving data.

This is not an IconView defect: IconView is only the log site that surfaced it. The same stream id and owner appear in a cluster of sibling incidents opened in the same burst across many view categories (Label, HtmlView, MarkdownView, LayoutStackView, ContainerView, DispatchView, MarkdownEditorView, …) — i.e. one owner-level event, fanned out across every component that was reading that node at that moment.

Where and when

One pod, one namespace (memex-cloud), a single sub-second burst: the fan-out signature of a whole page failing at once, not a steady leak. It is also not a one-off: comparable SyncStreamOwnerRefusedException bursts with different stream ids and owner addresses appear repeatedly over the ~30 minutes preceding this incident (other tenants/records in the same namespace), so the recycle-loop condition is recurring, not isolated to this one record.

Impact

The Overview area for that rejected payment does not render its content; every view bound to the node errors. The stream is designed to end with this error so readers can re-read, so the user-visible effect may be transient per page load — but while the owner keeps recycling, re-reads would keep failing. Not established: whether users were actually blocked for an extended period, or whether re-reads succeeded.

Not established

What kills the owner activations. Nothing in the burst shows why each activation of Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b dies before answering. The exception asserts the successor-dies pattern, but the underlying failure is not in these samples.
Whether the recycle loop persisted beyond this burst or has recurred for this same address.
Whether other pods observed the same instant (only one pod logged; a second pod's view of the same address would say whether the failure is address-local or cluster-wide).
I could not read the SyncStreamOwnerRefusedException / stream-owner implementation in this mesh — no source or doc node for it was found — so the owner lifecycle below is named from the exception's own wording, not from code I read.

Candidate causes and the reading that separates them

The owner activation crashes on init (e.g. an exception while loading that payment record), and the platform keeps recycling it. Predicts recurring activation/quiesce log lines for that exact address on the same pod, with an underlying exception just before each refusal. Reading: pod logs around the burst filtered to the owner address would show why each activation dies — that one log line likely names the real defect.
The node was deleted or moved while views still streamed it, producing activation churn that reads as refusal. Predicts the node is absent or relocated now. Reading: check whether Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b exists and its version/delete history around the burst.
A deliberate refusal (dispose/ownership handover) rather than a crash. The distinct-activation count is the discriminator the code measures; whether "successor dies before it can answer" is instrumented or inferred needs the MeshWeaver.Data.Serialization stream-owner source, which I could not reach from this mesh.

The recurring bursts against other owner addresses suggest cause 1 or 3 (address-independent machinery); if cause 2 were the whole story, it would not repeat across records.

Sibling incidents on the same stream/owner at the same instant: Label, HtmlView, MarkdownView, LayoutStackView, ContainerView, DispatchView incidents under Admin/_LogIncident (each ticketed per log site by the watcher — this cluster is one underlying event).
Earlier same-signature bursts on other streams/owners from the same pod in the ~30 minutes before this one.

Where to look

MeshWeaver.Data.Serialization — the type SyncStreamOwnerRefusedException and the stream-owner lifecycle that counts distinct refusing activations (source not present in this mesh; search the repo the platform routes this to).
Log site: MeshWeaver.Blazor.Components.IconView ("Loading '{property}' in area '{area}'") — victim, not suspect.
The node Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b and its version history.
Pod logs for the same pod around the burst, filtered to the owner address, for the activation-failure line that precedes each refusal.

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

Last seen: 2026-10-13 20:22:46Z
Pods: memex-portal-deployment-85f6665f88-mzv8m

Recent log lines

2026-10-13 20:22:46Z memex-portal-deployment-85f6665f88-mzv8m fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'icon' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream 0SFoN8p830CmrYYhEJYi-g: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.
2026-10-13 20:22:46Z memex-portal-deployment-85f6665f88-mzv8m fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream 0SFoN8p830CmrYYhEJYi-g: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.

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

This issue tracks the log site 3d33a3000718df06 (MeshWeaver.Blazor.Components.IconView), 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	`67dc689c96fe3558`
Log site	`3d33a3000718df06`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Detail	`Stream daxfo7{n}X4{n}yAQZdHkDPA0Q: 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-85f6665f88-mzv8m`
Occurrences	2
First seen	2026-10-13 20:22:46Z
Last seen	2026-10-13 20:22:46Z
Already folded here	4 fingerprint(s)
Incident	`Admin/_LogIncident/67dc689c96fe3558`
Triage called it	IconView icon loads abort with SyncStreamOwnerRefusedException while owner address Admin/Subscriptions/sglauser recycles without settling

What triage wrote about this fingerprint

Observed

The IconView Blazor component failed to load the icon and iconWidth properties of the area Overview/2/1/1/1/1/1/1/1 with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: sync stream daxfo70X40yAQZdHkDPA0Q gave up on its owner address Admin/Subscriptions/sglauser after 4 DISTINCT owner activations refused it, against a budget of 3 — the address is recycling in a LOOP, each successor dying before it can answer the stream. The exception message states that the stream ends with this error so its readers can re-read, and that the fault is at whatever is requesting the recycles, not at the stream or the view. The log site (MeshWeaver.Blazor.Components.IconView) is the observer, not the fault.

Where and when

A single burst on one pod of the memex-cloud deployment: both occurrences are the same instant, the same stream id, the same view reading two properties of one area — one recycle-loop event observed twice, not a steady rate. variants is 1: one shape only. The same exception text — "giving up on owner … 4 DISTINCT owner activations have refused this stream (budget 3)" — appears in the fleet's Ops/Logs archive against many other owner addresses (partitions such as Approvals, UWDeepfield, Chat, rbuergi, Hosting/Triage threads) going back to late September, so this refusal is a recurring fleet mechanism; this incident is that mechanism arriving at this log site with this owner.

Impact

Icons of the area Overview/2/1/1/1/1/1/1/1 do not render for whoever had that page open at the moment of the burst; the stream ends by design so a re-read can recover. The wider concern the message carries is at the owner address itself: a hub that cannot settle serves nothing of Admin/Subscriptions/sglauser while the loop runs. Judged on the numbers — two occurrences, one pod, one instant — this is a secondary-path defect with the framework's own recovery path intact, not an outage.

Not established

Why the address recycles. The incident carries no stack frame and no DisposeRequest reason; nothing in it names which recycler — or which fault — took the successive activations down.
Whether the loop continued after the stream ended. The evidence is the two log lines at the moment of giving up; whether a later activation of Admin/Subscriptions/sglauser settled is not in the incident.
Whether other log sites observed the same refusal at the same instant. This incident covers the IconView log site only; other components holding streams owned by the same address would log their own refusal under their own fingerprints, and none is folded here.
Whether the archived occurrences are the same defect. The budget and message are identical, but the owners, pods and dates differ, and no occurrence has been triaged to a cause.

Candidate causes and the reading that separates them

The framework documents four automatic recyclers that post DisposeRequests to a live address — NodeTypeRebindWatcher, WithOverlaySelfHeal, ArmStaleAssemblySelfHeal (Modules:AutoRecycleOnStaleBuild, ON fleet-wide on AKS) and PackageInstaller.SettleRetypedRoot — beside the operator surfaces (recycle verb, the Recycle job kind, governed Hosting/InstanceAction). Each candidate predicts a different next reading:

A self-heal watcher disposing the address repeatedly because each fresh activation comes up degraded (a failed compile, or a source query matching zero Code nodes so the re-activation rebuilds the pre-fix source). Predicts repeated [QUIESCE-START] lines for Admin/Subscriptions/sglauser whose reason reads "requested by itself — a rebind or self-heal recycle", and an owner NodeType record reading IsDirty / CompilationStatus = Error. Reading: the [QUIESCE-START] lines on the pod around the burst, plus the owner's NodeType record.
An external requester re-disposing the address as fast as it activates (operator recycle, recycle job, another hub's hub.RecycleNode). Predicts a [QUIESCE-START] reason naming the requester (an action node, a deployment, "run as system"). Reading: the same line — the reason distinguishes a self-recycle from a named requester.
Each successor dies on its own before it can answer — an init fault or a self-retire during activation, with no DisposeRequest at all. Predicts activation-phase fault lines for the address and no [QUIESCE-START]. Reading: the pod's activation log for Admin/Subscriptions/sglauser; the absence of QUIESCE-START rules out both recycler candidates.

The single most discriminating reading is the [QUIESCE-START] line for Admin/Subscriptions/sglauser at the moment of the burst: its Reason names the poster, and its absence points at a crash loop rather than a recycle loop.

Where to look

MeshWeaver.Data.Serialization — SyncStreamOwnerRefusedException and the owner-activation budget it enforces (the refusal site, not the fault).
src/MeshWeaver.Mesh.Contract/HubRecycleExtensions.cs (hub.RecycleNode) and the four-recyclers table in Stale State Until a Recycle — the lanes that can put an address into a dispose/reactivate loop, and the [QUIESCE-START] Reason convention.
Retiring an Activation — the constraint that a hub retiring itself after a transient init fault must fail its gate before it disposes.
The [QUIESCE-START] log lines for Admin/Subscriptions/sglauser on the affected pod are the first read.

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

Last seen: 2026-10-13 20:22:46Z
Pods: memex-portal-deployment-85f6665f88-mzv8m

Recent log lines

2026-10-13 20:22:46Z memex-portal-deployment-85f6665f88-mzv8m fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'icon' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream daxfo70X40yAQZdHkDPA0Q: giving up on owner Admin/Subscriptions/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.
2026-10-13 20:22:46Z memex-portal-deployment-85f6665f88-mzv8m fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream daxfo70X40yAQZdHkDPA0Q: giving up on owner Admin/Subscriptions/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.

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

This issue tracks the log site 3d33a3000718df06 (MeshWeaver.Blazor.Components.IconView), 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	`6984abe2a191d270`
Log site	`3d33a3000718df06`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Detail	`Stream ctBtZgYcpUKmU4{n}Z-{n}wZyQ: 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-85f6665f88-mzv8m`
Occurrences	2
First seen	2026-10-13 20:22:46Z
Last seen	2026-10-13 20:22:46Z
Already folded here	5 fingerprint(s)
Incident	`Admin/_LogIncident/6984abe2a191d270`
Triage called it	IconView sync stream ends after its owner address (rejected-payment record Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b) recycles through four activations without settling — recurrence of #6724 on a third pod

What triage wrote about this fingerprint

Observed

An IconView (MeshWeaver.Blazor.Components.IconView) loading the properties icon and iconWidth in area Overview/2/1/1/1/1/1/1/1 had its synchronization stream ctBtZgYcpUKmU47Z-1wZyQ ended with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: the owner address Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b went through 4 distinct owner activations, each refusing the stream, against a budget of 3 — the address recycling in a loop, each successor dying before it could answer. The exception's own text locates the defect at whatever requests the recycles, not at the stream or the view component; IconView is the reporting site, not the cause.

Duplicate notice — already filed as #6724

This is a recurrence of the same defect already filed as #6724 (triaged from incident Admin/_LogIncident/04d545c72ffa86f8): the identical exception, from the same IconView component reading the same properties, against the same owner address Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b, roughly half an hour earlier on a different pod, a different stream id, and a shallower area path (Overview/1/1/1/1/1/1). #6724 already carries the candidate-cause analysis; this ticket can be closed against it in seconds. What this sighting adds: a third distinct pod of the same deployment (so the loop is not pod-local to either earlier sighting), and independent confirmation that the owner node is still absent with no readable version history on this portal — consistent with the node having been deleted rather than merely unreadable from here.

Where and when

A single instant, one pod of the memex-cloud namespace, one stream ending reported once per property load. Coincidence check, read and not inferred: Store/_GitSync's last sync attempt (lastAttemptWasFinal, outcome Skipped) predates this burst by roughly a quarter of an hour, and no further sync attempt appears between then and this triage — no GitSync write coincides with this sighting. Earlier the same day, a wave of sibling incidents carrying the same exception text at other owners (a PartnerRe/Esl thread hub → #6709, OIB/WhatThisIsFor → #6711, and others) was triaged and filed separately; the give-up wording has been present in Ops/Logs since late September across many owners and pods, so this is one instance of a recurring family.

Impact

One reader's view of a rejected-payment record (the Overview area of Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b) failed to render its icon properties once. The stream ends with this error by design so its readers can re-read, so the view is expected to recover on the next render; no data was written or lost. The numbers do not support a blocking ruling.

Not established

What requested the recycles — nothing on the incident names the requester; the exception text points away from the stream. This remains the open question, and it belongs to Owner-recycle loop on Store/Payments/_Rejected payment view kills its sync stream; IconView 'icon'/'iconWidth' loads fail #6724.
The owner node's fate — it is absent now with no version history readable from this portal; whether it was deleted inside the window (and by what) was not determined.
Whether the loop is still active at that address after the give-up, and whether the reader's re-read recovered the view.
Whether the Overview/2/… area path or the rejected-payment record's own lifecycle has any bearing — not read.

Candidate causes, and the reading that separates them

Mirrors #6724; this sighting does not change the discriminator list, but the absence of a GitSync attempt at this burst instant weakens cause (1) for this sighting specifically:

The owner node was deleted or pruned under live client streams (e.g. by a Store writer or import). Predicts the node's absence and missing version history — both observed. Reading: Store/_GitSync's version history and the Store change feed for a delete event at that path; note no sync attempt was recorded at or immediately before this burst.
An activation-fault recycle loop — each successor activation dies before it can answer the stream (the retire-after-init-fault shape). Predicts repeated [QUIESCE-START] / recycle lines at that address in the seconds before the burst, each carrying a Reason naming the requester. Reading: the pod's log for that address — the single most decisive observation available.
A two-writer flap over the Store partition (alternating unattended writers each recycling the hub). Predicts alternating writer versions in the same window. Reading: Store install records and sync-source version history for the window.

Where to look

Prior filing for the same owner address and defect: Owner-recycle loop on Store/Payments/_Rejected payment view kills its sync stream; IconView 'icon'/'iconWidth' loads fail #6724 and its incident node Admin/_LogIncident/04d545c72ffa86f8.
Sibling family tickets filed the same day: Thread hub recycles in a loop — its sync stream ends with SyncStreamOwnerRefusedException and that thread's Changes-header badges fail to load #6709 (PartnerRe/Esl thread hub), Sync stream refuses after a Thread hub's owner activations die in a loop — LayoutStackView header load fails on one memex thread #6711 (OIB/WhatThisIsFor), plus the many un-triaged sibling incidents under Admin/_LogIncident from 17:17Z onward.
The exception and the owner-refusal budget: MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException in src/MeshWeaver.Data/Serialization/.
The Store partition's writers: Store/_GitSync (syncing Systemorph/MeshWeaver.Plugins, subdirectory Store) and the Store change feed for Payments/_Rejected/*.
The fleet-wide pattern: Ops/Logs entries carrying the "giving up on owner … DISTINCT owner activations" text (present since 2026-09-26).

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

Last seen: 2026-10-13 20:22:46Z
Pods: memex-portal-deployment-85f6665f88-mzv8m

Recent log lines

2026-10-13 20:22:46Z memex-portal-deployment-85f6665f88-mzv8m fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'icon' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream ctBtZgYcpUKmU47Z-1wZyQ: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.
2026-10-13 20:22:46Z memex-portal-deployment-85f6665f88-mzv8m fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream ctBtZgYcpUKmU47Z-1wZyQ: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.

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.

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

This issue tracks the log site 3d33a3000718df06 (MeshWeaver.Blazor.Components.IconView), 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	`0fe35bde1741db3e`
Log site	`3d33a3000718df06`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Detail	`Stream IGyFG7mKpU6xDUJA2KdWdg: 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-6bd97645d4-fwns9`
Occurrences	2
First seen	2026-10-14 07:26:58Z
Last seen	2026-10-14 07:26:58Z
Already folded here	6 fingerprint(s)
Incident	`Admin/_LogIncident/0fe35bde1741db3e`
Triage called it	Sync stream owner at a rejected-payment record (Store/Payments/_Rejected) recycles in a loop — IconView live loads end in SyncStreamOwnerRefusedException

What triage wrote about this fingerprint

Observed

A cross-hub synchronization stream (id IGyFG7mKpU6xDUJA2KdWdg) whose owner is the node hub at Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b ended with MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: 4 DISTINCT owner activations refused the stream against a budget of 3 — each successor activation of that address died before it could answer the subscribe. The reader that lost the stream here is IconView property loading (icon, iconWidth) on area Overview/2/1/1/1/1/1/1, namespace memex-cloud, pod memex-portal-deployment-6bd97645d4-fwns9.

This fingerprint is one log site's face of a single burst: six sibling LogIncidents (Label, ContainerView, HtmlView, MarkdownView, DispatchView, LayoutStackView) carry the same stream id, the same owner path and the same 4-activations/budget-3 reading, all logged within the same second on the same pod. They are the other property loads of the same failed view; the watcher files one ticket per log site.

Where and when

One pod, one namespace, one burst inside ~30 ms, one owner node (a single rejected-payment record's overview). Whether other pods of the deployment saw the same owner recycling is not established — the fingerprint's samples carry only this pod.

The same exception signature at other owners exists in the Ops logs (2026-09-26: owners Approvals, BinaryClickerV2, UWDeepfield/*; 2026-10-07: RFPProcessor, Essentials/OperationRequest, several Hosting/Triage thread paths). So the shape is not unique to this owner; whether those bursts share a cause with this one is not established.

Impact

One tenant's rejected-payment overview failed to load its live view at that instant. The stream ends with this error by design so its readers can re-read, so the harm is a momentary, narrow user-visible failure — not data loss, not a wrong result.

Not established

What requested the recycles. The exception names the recycling address, not the recycler; nothing on the incident says who issued the repeated teardowns.
Why each of the 4 activations died before it could answer — no activation-side fault is on the incident.
Whether the loop continued after lastSeen.
Whether Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b still exists on the instance: a read from this (control) instance returns Not found, which may be partition scoping rather than deletion.

Candidate causes and the reading that separates them

Something is repeatedly issuing dispose/recycle requests at that address — a stale-build recycle, a NodeType enrichment watch, or a competing writer of the Store partition. Predicts teardown/recycle log lines naming the requester at that address in the seconds before the burst. Reading: the owner hub's disposal lines ([QUIESCE-START], the Registrants= diagnostics) on the pod.
Each activation of that node hub faults during its own startup — a per-record fault in the Store plugin's view model for a _Rejected payment record, so every successor dies before answering. Predicts a matching error at that address's activation site. Reading: error/fault logs for Store/Payments/_Rejected/… activation in the same window.
The record was deleted or recreated concurrently — the version-less recycle-broadcast class of change event (see Live Mirrors and the Change Feed), tearing the owner down and rebuilding it faster than the subscribe could be answered. Predicts delete/recreate events for that node path in the same window. Reading: the node's version history / change-feed events around the burst.

A hub census (HubCensusByOwner, per /Doc/Architecture/SyncHubPopulation §8) on the pod, read during a recurrence, separates a wedged teardown (the owner address persisting at ShutDown, IsDisposing=true) from a healthy recycle loop (successors reaching Started and dying again).

Where to look

src/MeshWeaver.Data/Serialization/SynchronizationStream.cs — the owner-refusal budget that mints SyncStreamOwnerRefusedException.
The SubscribeRequest / owner-disposal NACK handling in DataExtensions / MeshDataSource (RegisterOwnerDisposingNack).
The Store plugin's view model for _Rejected payment records — the owner address's own activation path.
Architecture context: /Doc/Architecture/SyncHubPopulation (hub lifecycles, retire-and-replace, registry removals), /Doc/Architecture/LiveMirrorsAndTheChangeFeed (recycle broadcasts).

Possibly a duplicate

Check the tickets the filer opens from the six sibling incidents on the same stream before working this one — same evidence, one defect instance; a human can fold them in seconds.

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: 2 more since the last update (2 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.Components.IconView[0]
      Loading 'icon' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream IGyFG7mKpU6xDUJA2KdWdg: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.
2026-10-14 07:26:58Z memex-portal-deployment-6bd97645d4-fwns9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream IGyFG7mKpU6xDUJA2KdWdg: giving up on owner Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b — 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.

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

This issue tracks the log site 3d33a3000718df06 (MeshWeaver.Blazor.Components.IconView), 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	`c808344675bbdedf`
Log site	`3d33a3000718df06`
Category	`MeshWeaver.Blazor.Components.IconView`
Severity	Error
Exception	`MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException`
Detail	`Stream nZAlMSigYEeetBkkgrZ0rA: 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-6bd97645d4-fwns9`
Occurrences	2
First seen	2026-10-14 07:26:58Z
Last seen	2026-10-14 07:26:58Z
Already folded here	7 fingerprint(s)
Incident	`Admin/_LogIncident/c808344675bbdedf`
Triage called it	Sync stream ends after owner-activation recycle loop on Admin/Subscriptions/sglauser exhausts the re-arm budget (stream nZAlMSigYEeetBkkgrZ0rA)

What triage wrote about this fingerprint

Observed

The sync stream's recycle ride-out (JsonSynchronizationStream's re-arm latch, MeshWeaver.Data) gave up on stream nZAlMSigYEeetBkkgrZ0rA and ended it with SyncStreamOwnerRefusedException after 4 distinct owner activations of the hub owning Admin/Subscriptions/sglauser (namespace memex-cloud) refused it — one past the MaxRecycleReArms budget of 3. Per the design (Riding Out a ShuttingDown Address) this is the many owners, many probes shape: the owner address recycled in a loop, each successor activation dying before it could answer a re-ask.

The give-up surfaced at this incident's two MeshWeaver.Blazor.Components.IconView read sites — the icon and iconWidth properties in area Overview/2/1/1/1/1/1/1/1 — and, in the same sub-second window, at sibling read sites of the same stream: DispatchView (6), MarkdownView (3), HtmlView, Label, LayoutStackView, ContainerView (incidents aebee61e6325fca7, d0725adb9e7a8d3d, cfbde2ffdf2d3b31, 35b45f73bdabd399, 0f068e74f04f62bb, 0750968ec7cf42a4). That is one stream fault fanned out to its subscribers, not seven failures.

The give-up itself is designed behaviour on the stream's side: its own message names the recycler, not the stream, as the defect site.

Where and when

All samples fall within a fraction of a millisecond of one another (07:26:58.468Z) on one pod, memex-portal-deployment-6bd97645d4-fwns9 — a single give-up event on one stream, not a recurring rate, and not fleet-wide. In the same second, other streams also gave up on this pod: IGyFG7mKpU6xDUJA2KdWdg (fanned across at least five view components) and Qlv5xA9kB0WbKiLVHT_zDA (ThreadChatView). Multiple distinct owner addresses hitting the same budget in one window points at a cluster-wide event on that pod, not a fault specific to the subscription node.

The same exception family also burst on 2026-10-13 ~20:05–20:28Z on a different pod (memex-portal-deployment-85f6665f88-mzv8m) against other owners (e.g. Store/Payments/_Rejected/973c8980476a49cba8b8059e8e91bf4b), so this is at least the second burst in ~11 hours across deployment generations.

Impact

The portal overview area rendering off Admin/Subscriptions/sglauser failed to load for one user-facing view for the duration of the loop. By design the ended stream's readers recover on their own signal (MeshNodeStreamCache evicts the faulted entry; the layout area classifies the type as transient and re-subscribes, bounded by RetryAreaWithBackoff), so the render failure is transient unless the loop persists. No evidence of data loss or corruption; the owner node itself is intact and Active.

Not established

What requested the recycles. The incident carries no line naming the teardown requester or the stated reason — the exception names the recycler only as a class.
Whether the loop is still occurring — one burst was observed; no second window was read.
Whether the give-ups on the other two streams in the same second shared one recycler — only their existence was read, not their owner addresses or activation tokens.
Whether this burst fell inside a pod roll — no deployment event log was read for that window.

Candidate causes and the reading that separates them

A pod roll with hand-off hops between lingering silos — the documented known limit of Activity tracking fails to hydrate user activity node — inner UpdateNode aborts with no initial state within 30s #5256: each migration hop to another leaving silo is a distinct activation on the budget. This cause fits the evidence best on its face: multiple unrelated owner addresses spent the same budget in the same second on one pod, and the 2026-10-13 burst sat on a different pod of the same deployment, consistent with a roll replacing pods. Predicts the burst sits inside a roll window. Discriminating reading: the deployment/roll events around 07:26:58Z, and the give-up Warning's activation tokens (whether the 4 refusals carry 4 distinct ShutdownNack activations with hand-off placement hints).
A repeated failing hub build / an initialization gate that can never open on the Admin/Subscriptions/sglauser hub — each activation dies in bring-up before it can answer. Predicts bring-up discard Errors and deferred-delivery refusals naming this one address, and does NOT explain the other two streams giving up in the same second. Discriminating reading: Warning/Error lines naming Admin/Subscriptions/sglauser in the same window, and the ShutdownNack what clause on its refusals (who asked for the teardown and the reason stated).
A stale-assembly self-heal loop / module live-update churn — a LOOP means something keeps requesting teardowns (cf. the Message hub discards deferred SubscribeRequests on Orleans deactivation instead of draining them #5718/Overlay self-heal staleness verdict recycles every Store/Plugin-bound hub at once, discarding 105 deferred requests mid-burst #4866 module-update shapes). Predicts repeated module activation/landing events at that time. Discriminating reading: module activation records and PendingModuleActivations fingerprints in the window, plus GetDiagnostics on the owner's NodeType for a compile error driving repeated recycles.

Possibly a duplicate

This is the same failure class as #6708 (filed 2026-10-13 from incident Admin/_LogIncident/6939d9fef79536d4 — same exception, same budget exhaustion, different owner address and pod). If these bursts share one systemic recycler (most plausibly the roll window of #5256's known limit), a human may close this against that issue; this ticket is filed so the sglauser burst and the multi-stream fan-out of 07:26:58Z are on record.

Where to look

Riding Out a ShuttingDown Address — the two-axis budget, the two recycling shapes, the give-up contract, and Activity tracking fails to hydrate user activity node — inner UpdateNode aborts with no initial state within 30s #5256's known roll limit
JsonSynchronizationStream's recycle re-arm latch (MaxRecycleReArms, ChargeReArmBudget, RecyclingShape) — MeshWeaver.Data
ShutdownNack — MeshWeaver.Messaging.Contract: the activation token the counters read, and the what clause naming the teardown requester
The owner node: Admin/Subscriptions/sglauser (namespace memex-cloud)
Sibling incidents on the same stream, same instant: Admin/_LogIncident/aebee61e6325fca7, d0725adb9e7a8d3d, cfbde2ffdf2d3b31, 35b45f73bdabd399, 0f068e74f04f62bb, 0750968ec7cf42a4

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: 2 more since the last update (2 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.Components.IconView[0]
      Loading 'icon' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream nZAlMSigYEeetBkkgrZ0rA: giving up on owner Admin/Subscriptions/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.
2026-10-14 07:26:58Z memex-portal-deployment-6bd97645d4-fwns9 fail: MeshWeaver.Blazor.Components.IconView[0]
      Loading 'iconWidth' in area 'Overview/2/1/1/1/1/1/1/1' in Area Overview/2/1/1/1/1/1/1/1
      MeshWeaver.Data.Serialization.SyncStreamOwnerRefusedException: Stream nZAlMSigYEeetBkkgrZ0rA: giving up on owner Admin/Subscriptions/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.

Owner-recycle loop on Store/Payments/_Rejected payment view kills its sync stream; IconView 'icon'/'iconWidth' loads fail #6724

Description

Observed

Where and when

Impact

Not established

Candidate causes and the reading that separates them

Where to look

Evidence

Activity

systemorph-com commented on Oct 13, 2026

Observed

Where and when

Impact

Not established

Candidate causes and the reading that separates them

Where to look

systemorph-com commented on Oct 13, 2026

Observed

Where and when

Impact

Not established

Candidate causes, and the reading that separates them

Where to look

systemorph-com commented on Oct 13, 2026

Observed

Where and when

Impact

Not established

Candidate causes and the reading that separates them

Related

Where to look

systemorph-com commented on Oct 13, 2026

systemorph-com commented on Oct 13, 2026

Observed

Duplicate notice — already filed as #6724

Where and when

Impact

Not established

Candidate causes, and the reading that separates them

Where to look

rbuergi commented on Oct 14, 2026

systemorph-com commented on Oct 14, 2026

systemorph-com commented on Oct 14, 2026

Observed

Where and when

Impact

Not established

Candidate causes and the reading that separates them

Possibly a duplicate

Where to look

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions