ProviderCredentialSeed issues its boot-time SaveMeshNodeRequest from the mesh (router) hub instead of a node-operation hub

[systemorph-com]

What is failing

MeshWeaver.AI.ProviderCredentialSeed posts the SaveMeshNodeRequest that writes a provider's API key onto its node (here Provider/Anthropic) with the mesh hub itself as sender. The mesh hub is the router and must not be an end of a work delivery. MessageHub's router-traffic guard caught this and logged it. The guard reports each role and message type only once per hub, so the count here is the first report, not a count of how often it happens.

Probable cause (high confidence)

The guard's call site points at the continuation inside ProviderCredentialSeed.Write (<>c__DisplayClass12_0.<Write>b__1, ProviderCredentialSeed.cs:483), reached from an Rx Select → Take → Do chain. The role is sender and the target is the owning node Provider/Anthropic, so the target is correct and only the issuing hub is wrong. The seed runs on process boot and uses the mesh hub it was handed. It does not hop onto MeshExtensions.NodeOperationIssuingHub(), which is the seam the guard names for a node-lifecycle write. The time matches the ops action restart memex so ProviderCredentialSeed fills Provider/Anthropic's key: the rolling restart finished at 07:19:45Z and the seed wrote at 07:19:26Z. That restart was the first time in a while that the seed had an empty key to fill, which probably explains why this has not been reported before.

Impact

Low in volume: one post per pod boot, and only when a provider node's key is empty and gets seeded. Two things are still open, and I can't close them from the log:

• Did the write land? The guard logs the post but doesn't stop it. Replies to a router-sent request have nowhere sensible to go, so the save's response or any failure could be silently lost. Check that Provider/Anthropic now holds the key from this generation. If the seed silently fails, the portal's default model provider stays unconfigured (a 401 on every Anthropic call), and this should be re-ruled up to sev:H.
• Companion incident 2a40878fdda81b44: ROUTER_TRAFFIC: RawJson has the mesh hub as sender, with the same sender mesh/3aB56l7Rw0KRbkGbCNit8Q, the same target Provider/Anthropic, logged 1 ms later. It is the same delivery reported at the transport layer, so it is a duplicate of this ticket and is fixed by the same change.

No existing incident or issue covers ProviderCredentialSeed. The other ROUTER_TRAFFIC ORIGIN incidents (GetDataRequest, SubscribeRequest, DeliveryFailure and others) come from different call sites.

Where to look

• MeshWeaver.AI.ProviderCredentialSeed.Write, the lambda at ProviderCredentialSeed.cs:483 that posts SaveMeshNodeRequest. Issue it from hub.NodeOperationIssuingHub() rather than from the mesh hub.
• Background: Message-Based Communication and A Request a Hub Sends to Itself.

---

Evidence

Fingerprint	e479f679c8943a8f
Category	MeshWeaver.Messaging.MessageHub
Severity	Error
Top frame	MeshWeaver.AI.ProviderCredentialSeed+<>c__DisplayClass12_0.<Write>b__1 (ProviderCredentialSeed.cs:483)
Namespace	memex
Pods	memex-portal-deployment-7fd48bdcd4-v96dx
Occurrences	1
First seen	2026-09-26 07:19:26Z
Last seen	2026-09-26 07:19:26Z
Routing	not determined — no configured route matches the category MeshWeaver.Messaging.MessageHub. 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-26 07:19:26Z memex-portal-deployment-7fd48bdcd4-v96dx fail: MeshWeaver.Messaging.MessageHub[0]
      ROUTER_TRAFFIC ORIGIN: SaveMeshNodeRequest was POSTED with the mesh hub as sender (sender: mesh/3aB56l7Rw0KRbkGbCNit8Q, target: Provider/Anthropic). The mesh hub is the ROUTER and must not be an end of a work delivery. If the role above includes 'sender', this post LEFT the router: hop it onto the seam that matches what this delivery IS — MeshExtensions.NodeOperationIssuingHub() for a node LIFECYCLE write, MeshExtensions.ReadIssuingHub() for a bounded one-shot READ, MeshExtensions.StreamSubscribingHub() for a remote stream SUBSCRIPTION. The three are NOT interchangeable and the wrong one fails SILENTLY: ReadIssuingHub() registers no handlers by design, so a subscription hopped onto it stops reporting AND stops receiving data (#4614). If the role above includes 'target', ask where that target CAME FROM, because the two cases have opposite fixes: if this call site CHOSE the router as the destination, the call site is the offender — address the owning node instead (MeshExtensions.NodeOperationTarget()); if the target was read off an incoming request or subscription (request.Subscriber, ResponseFor(delivery) — SubscribeAck, DataChangedEvent, StreamErrorEvent and StreamEndedEvent all are), then this call site is the innocent answering half and the hub to move is the one that SUBSCRIBED or REQUESTED (#4697). 'sender AND target' means both apply. Reported once per role+type for this hub. Call site:
         at MeshWeaver.AI.ProviderCredentialSeed+<>c__DisplayClass12_0.<Write>b__1 (ProviderCredentialSeed.cs:483)
         at System.Reactive.Linq.ObservableImpl.Do`1+OnNext+_.OnNext
         at System.Reactive.Sink`1.ForwardOnNext
         at System.Reactive.Linq.ObservableImpl.Take`1+Count+_.OnNext
         at System.Reactive.SafeObserver`1+WrappingSafeObserver.OnNext
         at System.Reactive.Sink`1.ForwardOnNext
         at System.Reactive.Linq.ObservableImpl.Select`2+Selector+_.OnNext
         at MeshWeaver.Messaging.AccessC…[truncated]

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