Repository navigation
Bulk stream-teardown flood saturates the memex-cloud mesh hub turn loop, tripping the aggregate action-block breaker #5532
Description
What is failing. A single hub on memex-cloud (mesh/YxuIePH430S3wXXs-HRa8A) received a burst of sheddable infrastructure traffic — predominantly StreamEndedEvent, with some HeartBeatEvent — that drove its single-threaded action-block inbound queue past the 10,000-message aggregate watermark within seconds. The aggregate breaker shed the sheddable traffic as designed (user-facing and lifecycle messages are never shed), so the hub stayed alive, but an amplifying source is still flooding this block far past its drain rate.
Probable cause. The shape of the shed traffic points at a bulk stream teardown: hundreds of sync/area streams ended in rapid succession (e.g. a disconnecting client that held many subscriptions, a mass cancel, or a teardown that itself re-emits). This is the exact scenario Action-Block Wedge Prevention Invariant 3 was built to survive — the breaker worked; the source that amplified the flood is the defect to find. Confidence: medium — the log tells us what flooded (StreamEndedEvent at scale) but not which sender or client drove it; a delivery fate-trail (SHED_AGGREGATE) analysis on that hub will identify the amplifier.
Impact. 454 overload events in ~36 seconds on one pod and one hub. User-facing messages were protected by the shed policy, so the likely user effect is latency/stalls for whoever was active on that hub's partition during the window, not message loss. Not a systemic outage — one hub, one pod, one window.
Where to look. Start with MeshWeaver.Messaging.MessageService ingestion logging on pod memex-portal-deployment-5f95fb94dc-pkhnc, hub mesh/YxuIePH430S3wXXs-HRa8A, window 2026-09-23 13:36:18–13:36:54 UTC: pull the shed deliveries' SHED_AGGREGATE fate trails and MessageStormBreaker.AggregateSheds to identify the sender(s) emitting the StreamEndedEvent storm. Then inspect the stream-teardown / StreamEndedEvent emit sites (SynchronizationStream, area streams) for a teardown path that emits per-stream endings without coalescing, and any client that holds very many streams on this hub. Related background: #1200 (legitimate wide fan-out vs breaker keys) and #1485 (envelope-vs-payload exemption checks) — if the flood turns out to be legitimate bulk fan-out rather than a defect, this ticket becomes 'raise/override the hub watermark' via MessageHubConfiguration.WithAggregateWatermark(...) instead.
Evidence
| Fingerprint | f2efe2be834b6801 |
| Category | MeshWeaver.Messaging.MessageService |
| Severity | Error |
| Namespace | memex-cloud |
| Pods | memex-portal-deployment-5f95fb94dc-pkhnc |
| Occurrences | 454 |
| First seen | 2026-09-23 13:36:18Z |
| Last seen | 2026-09-23 13:36:54Z |
| Routing | not determined — no configured route matches the category MeshWeaver.Messaging.MessageService. This repository is the configured fallback, not a finding about who owns the fault; the category names the LOGGER, which may not be the subject. |
Recent log lines
2026-09-23 13:36:53Z memex-portal-deployment-5f95fb94dc-pkhnc fail: MeshWeaver.Messaging.MessageService[0]
ACTION-BLOCK OVERLOAD in hub mesh/YxuIePH430S3wXXs-HRa8A: inbound queue depth 10000 crossed the aggregate watermark 10000. Shedding sheddable [CanBeIgnored] traffic (e.g. HeartBeatEvent) at ingestion to keep the single-threaded turn loop draining — user-facing and lifecycle messages are NEVER shed. An amplifying source (many distinct keys) is driving this block past its drain rate; find and fix it.
2026-09-23 13:36:54Z memex-portal-deployment-5f95fb94dc-pkhnc fail: MeshWeaver.Messaging.MessageService[0]
ACTION-BLOCK OVERLOAD in hub mesh/YxuIePH430S3wXXs-HRa8A: inbound queue depth 10000 crossed the aggregate watermark 10000. Shedding sheddable [CanBeIgnored] traffic (e.g. StreamEndedEvent) at ingestion to keep the single-threaded turn loop draining — user-facing and lifecycle messages are NEVER shed. An amplifying source (many distinct keys) is driving this block past its drain rate; find and fix it.
2026-09-23 13:36:54Z memex-portal-deployment-5f95fb94dc-pkhnc fail: MeshWeaver.Messaging.MessageService[0]
ACTION-BLOCK OVERLOAD in hub mesh/YxuIePH430S3wXXs-HRa8A: inbound queue depth 10000 crossed the aggregate watermark 10000. Shedding sheddable [CanBeIgnored] traffic (e.g. StreamEndedEvent) at ingestion to keep the single-threaded turn loop draining — user-facing and lifecycle messages are NEVER shed. An amplifying source (many distinct keys) is driving this block past its drain rate; find and fix it.
2026-09-23 13:36:54Z memex-portal-deployment-5f95fb94dc-pkhnc fail: MeshWeaver.Messaging.MessageService[0]
ACTION-BLOCK OVERLOAD in hub mesh/YxuIePH430S3wXXs-HRa8A: inbound queue depth 10000 crossed the aggregate watermark 10000. Shedding sheddable [CanBeIgnored] traffic (e.g. StreamEndedEvent) at ingestion to keep the single-threaded turn loop draining — user-facing and lifecycle messages are NEVER shed. An amplifying source (many distinct keys) is driving this block past its drain rate; find and fix it.
2026-09-23 13:36:54Z memex-portal-deployment-5f95fb94dc-pkhnc fail: MeshWeaver.Messaging.MessageService[0]
ACTION-BLOCK OVERLOAD in hub mesh/YxuIePH430S3wXXs-HRa8A: inbound queue depth 10000 crossed the aggregate watermark 10000. Shedding sheddable [CanBeIgnored] traffic (e.g. StreamEndedEvent) at ingestion to keep the single-threaded turn loop draining — user-facing and lifecycle messages are NEVER shed. An amplifying source (many distinct keys) is driving this block past its drain rate; find and fix it.
Re-addressed by the current identity function: this incident inherited 7a92a4f2b427a9ef (Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.
Opened automatically from Admin/_LogIncident/f2efe2be834b6801. Recurrences are folded into this issue rather than opening new ones.
Activity
rbuergi commentedon Sep 24, 2026
Found a sender from code that is pure waste by construction. Fixed in #5635 (merged,
bf5ac85526), awaiting roll.The amplifier.
JsonSynchronizationStreampostsStreamEndedEventfrom every owner-side stream disposal (#2191), and that included the disposal the SUBSCRIBER asked for (UnsubscribeRequest→hub.Dispose()). By then the subscriber'ssync/hub had already disposed itself, so the announcement crossed the subscriber pod's mesh hub only to be dropped there ([CanBeIgnored]). Now take a subscriber that releases N mirrors at once, for example a cache hub going down: it sends NUnsubscribeRequests, and N owners each send oneStreamEndedEventback through the same router turn loop. That is one sender shape producing N distinct-key sheddable messages to ONE hub, which is what this ticket describes.Fix (root, not batching): the owner's sync hub records that the subscriber ended it (
SynchronizationStream.MarkSubscriberEnded, set in theUnsubscribeRequesthandler before dispose), and the announcement skips that end. Owner-side ends (idle release,EvictClientSubscriptions) are still announced.SubscriberReleaseIsNotAnnouncedBackTest: a release gives 0 announcements, and the owner-side end (the control) gives 1. With the fix disabled it fails with "expected 0 … but found 1". Doc:LiveMirrorsAndTheChangeFeed(step 5).Not established: which emitter produced the 2026-09-23 13:36Z burst on
mesh/YxuIePH430S3wXXs-HRa8A. The other emitter,Workspace.AnnounceRecycleToClientSubscriptions, sends one event per LIVE subscriber of a recycled hub. Those events are needed, and they are not changed here. Telling the two apart needs aLogsread of that window (theSHED_AGGREGATEfate trails, and the sender address on the droppedStreamEndedEvents). The control instance is disconnected for this session.Deployed: memex.meshweaver.cloud runs core
9a61fed964, which predates this. Verification after the roll: no aggregate-watermark trips sheddingStreamEndedEventon a replica carryingbf5ac85526. If they recur there, read the sender. A sender that is a carrier hub (nodeops) points at the recycle announcer.rbuergi commentedon Sep 24, 2026
Post-roll sweep 2026-09-24 ~06:50Z: the fix is not live on either portal yet
What is running.
/api/versionreturns9a61fed964.Ops/Status/memex-cloud(06:42:00Z) shows 4/4 replicas on3.0.0-ci.9263. CD run 9263 built core9a61fed964with Plugins41bcfe968f./api/versionreturns39f49494eb.Ops/Status/memexshows the serving pods on3.0.0-ci.9218, which is core39f49494ebwith Pluginse9d9283abe. A third pod, onci.9260, is unready, so the roll isconverged: false.This issue's fix: #5635 (
bf5ac85526). It is not an ancestor of either running build (git merge-base --is-ancestor, exit 1).Where it is.
3.0.0-ci.9287(CD run35956222018) is corebf5ac85526with Pluginsc4795a8d5b, and it contains this fix. The registry has sealed it. memex-cloud's self-updater logged[SelfUpdate] handing 3.0.0-ci.9287 to the control lane (https://memex.systemorph…)at 06:47Z. So the roll now waits on the control instance, which is an owner step and was not done here.Still open. It closes on a post-roll reading once a
ci.9287-or-later image serves the namespace this fingerprint fires in.rbuergi commentedon Sep 24, 2026
Closing: fix live, no recurrence for ≥ 6 h, positive control present
Image. memex-cloud (memex.meshweaver.cloud) serves
3.0.0-ci.9291./api/versionreturns core140c5fb7ae, andOps/Status/memex-cloud(sampled 14:49Z) shows all 4 replicas on that tag,converged: true. The Plugins half isb3601fecbe: the portal-ai build job of CD run 35970157348 (job 107542528900) logsHEAD is now at b3601fe. The first pods of this ReplicaSet (memex-portal-deployment-589ff8f895) started at 08:41:05Z and 08:42:17Z. More pods of the same ReplicaSet, on the same image, joined later (gqsfn at 14:06Z, vw5jj at 14:10Z, and others). The control instance memex.systemorph.com still serves core39f49494eb.Window and method. I ran
LogsInstanceActions on memex.meshweaver.cloud between 14:43Z and 14:54Z, withsinceMinutes370/375, filtered to this ReplicaSet with| pod=~"memex-portal-deployment-589ff8f895-.+". That is ≥ 6 h of this image only, from 08:41Z to about 14:50Z. Coverage control:Ops/logs-memexcloud-20260924-close6h-c-bootcoverage(warm-up complete) lands 9 lines from 9 pods of this ReplicaSet. The earliest are ghgjt, vn49b and tp564 at about 08:51Z, so the window reaches back to the first boots.Fix: #5635 (
bf5ac85526). It is an ancestor of the running build (git merge-base --is-ancestor, exit 0).|~ "(?i)ACTION-BLOCK OVERLOAD"(Ops/logs-memexcloud-20260924-close6h-f-overload)|~ "MeshWeaver.Messaging.MessageService"(Ops/logs-memexcloud-20260924-close6h-c-messageservice)Before the fix, this fired as a single 454-line burst (2026-09-23 13:36Z). Across ≥ 6 h that includes pod joins and replacements, the fixed image logged no overload line in any hub.
Closing as completed. If this shape recurs on an image that contains the fix, reopen and treat it as a new path. Readings were taken read-only through the
memexMCP.systemorph-com commentedon Oct 11, 2026
Reopened — this fault is happening again.
Still occurring: 2 more since the last update (456 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488fRecent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.systemorph-com commentedon Oct 11, 2026
Reopened — this fault is happening again.
Still occurring: 2 more since the last update (456 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488fRecent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.test(data): reproduce the per-stream recycle announcement fan-out
systemorph-com commentedon Oct 12, 2026
Still occurring: 1 more since the last update (457 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488f,memex-portal-deployment-6c95ffcd84-h4tr5Recent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.fix(data): announce an owner recycle once per subscriber, not per stream
rbuergi commentedon Oct 12, 2026
Status of the fix, PR #6539 (head
81cba5dc38), 2026-10-12 16:35Z:MeshWeaver Build and Test: 23 of 24 jobs are green. The remaining one,Dependent suites (MeshWeaver.Plugins), is still running. No job has failed.Automatic review answered: "the automatic review has not landed — no review by the automatic reviewer on this pull request". The reviewer opened 0 threads and nothing is unanswered. That needs the review to land, or a maintainer re-request orreview-waived. An agent can do neither.Not checked: whether the 2026-10-12 01:26:43Z occurrence (
mesh/xf4z3K4sdEOX0Jhh-nBN…on…-6c95ffcd84-h4tr5) has the same producer as the 10-11 19:21Z one that #6539 is built on.systemorph-com commentedon Oct 12, 2026
Still occurring: 2 more since the last update (459 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488f,memex-portal-deployment-6c95ffcd84-h4tr5,memex-portal-deployment-5b786c4466-4fs6cRecent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.systemorph-com commentedon Oct 13, 2026
Still occurring: 7 more since the last update (466 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488f,memex-portal-deployment-6c95ffcd84-h4tr5,memex-portal-deployment-5b786c4466-4fs6c,memex-portal-deployment-54856649cb-m2jn9,memex-portal-deployment-54856649cb-4hwrpRecent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.Merge origin/main into #6539
test(data): pin every mirror's re-ask and the per-stream fallback of …
rbuergi commentedon Oct 13, 2026
#6539's review threads are now answered and the PR is armed (merge). On 2026-10-13 its only red was
Automatic review answered: three Copilot threads from 10-12 18:02Z that no push had addressed. Commit1658104456fixes all three:60 from 60 distinct mirrors, carrierclient/…=3;CoalesceRecycleEndsis aninternalseam over plain rows, and a unit test pins the rolling-deploy fallback: an undeclared subscriber still gets one plain end per stream. Negative control run:{"l1"}vs{"l1","l2","l3"};AcceptsStringSplicedoc wording.Each thread has a reply naming the commit. The 2026-10-13 00:08Z overloads in the last fold are the shape #6539 addresses: a recycle cascade's per-stream ends on
portal/nodeops-…. Closes on: noACTION-BLOCK OVERLOAD … StreamEndedEventacross a module live update after #6539 rolls.systemorph-com commentedon Oct 14, 2026
Still occurring: 1 more since the last update (467 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488f,memex-portal-deployment-6c95ffcd84-h4tr5,memex-portal-deployment-5b786c4466-4fs6c,memex-portal-deployment-54856649cb-m2jn9,memex-portal-deployment-54856649cb-4hwrp,memex-portal-deployment-7d5c89fc56-8ljrwRecent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.systemorph-com commentedon Oct 15, 2026
Still occurring: 2 more since the last update (469 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488f,memex-portal-deployment-6c95ffcd84-h4tr5,memex-portal-deployment-5b786c4466-4fs6c,memex-portal-deployment-54856649cb-m2jn9,memex-portal-deployment-54856649cb-4hwrp,memex-portal-deployment-7d5c89fc56-8ljrw,memex-portal-deployment-6d4df8d45f-ktwf2Recent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.systemorph-com commentedon Oct 15, 2026
Still occurring: 1 more since the last update (470 total).
memex-portal-deployment-5f95fb94dc-pkhnc,memex-portal-deployment-b79b66b68-w488f,memex-portal-deployment-6c95ffcd84-h4tr5,memex-portal-deployment-5b786c4466-4fs6c,memex-portal-deployment-54856649cb-m2jn9,memex-portal-deployment-54856649cb-4hwrp,memex-portal-deployment-7d5c89fc56-8ljrw,memex-portal-deployment-6d4df8d45f-ktwf2Recent log lines
Re-addressed by the current identity function: this incident inherited
7a92a4f2b427a9ef(Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.rbuergi commentedon Oct 15, 2026
The 2026-10-15 00:47Z overloads came from the same module-swap wave as the #6520 and #5718 recurrences, on an image that already contains #6539.
memex-portal-deployment-6d4df8d45f-ktwf2in namespacememex-cloud(Ops/Actions/rw-6520-memexcloud-cqiq-20261015on the control instance). Its mesh hub ismesh/CQIqeIjW80aQ96e3VctZHg, and the same suffix is onportal/nodeops-CQIq…. The generation is the 3.1.10841 roll (completed 2026-10-14 23:44:40Z). Every main commit from 2026-10-14 05:41Z onward contains fix(data): announce an owner recycle once per subscriber, not once per stream #6539 (bd72dab2d5), so these overloads are not a stale image.ModuleLiveUpdate: MeshWeaver.Graph.Views swapped live …;MeshWeaver.OgCardandMeshWeaver.Markdown.Exportappear in the same minute). It recycled every live per-node hub. Every NodeType definition hub among them then started its ownRecycleCascade, and each cascade posted oneDisposeRequestper stored address of its network from the node-operation issuing hub (portal/nodeops-…). The cascade lines on this pod (Ops/Actions/rw-6520-memexcloud-wave-20261015, 289 lines across the namespace) give fan-outs of up to 409 addresses per cascade, with about 200 cascades. So tens of thousands of disposes went through that one issuing hub. My inference, which I did not measure: each disposed hub ends its streams, and that would produce theStreamEndedEventtraffic the breaker names.CascadedFrom, so it no longer starts those cascades, and one landing pass is one wave instead of one per module. That removes the per-definition fan-out fromportal/nodeops-….Not established:
Information, which did not reach Loki for this namespace) both fall in that window, and the shed fate trail was not read.Closes on: no
ACTION-BLOCK OVERLOADonportal/nodeops-…during a module live update after #6800 rolls.rbuergi commentedon Oct 16, 2026
Closing: the producer named in the last comment is fixed, merged and running.
RecycleCascadeand posted oneDisposeRequestper address throughportal/nodeops-…, about 200 cascades with up to 409 addresses each.4a308d1dc0): one landing is one recycle wave, and that wave does not cascade. feat(recycle): a NodeType recycle cascade is ONE ActivationRecycle request (#6520) #6810 (64908a635e) makes a cascade a singleActivationRecyclerequest.9a3809f308, which/api/versionreports on all three portals (read 2026-10-16 ~05:40Z).{namespace="memex-cloud"} |~ "(?i)ACTION-BLOCK OVERLOAD", 2026-10-16 00:28Z to 05:48Z, read 0 lines (Ops/Actions/iw-mc-overload-since-0028-20261016, control instance). No module swap ran in that window either (|~ "(?i)swapped live"read 0). So the zero shows the breaker is quiet, not the fix under a swap wave.If the overload returns on an image that contains #6800, reopen this issue with the pod's producer.