You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e30e4d7
Browse filesBrowse the repository at this point in the historyBrowse files
docs: draw the load-balancer case as two replicas with separate buses
Replace the sequence diagram on the Subscriptions page with a small
flowchart: each replica is a box holding its own bus, the listen stream is
subscribed to one, the tool call publishes to the other, and a dashed
outline marks the shared bus that is missing between them.
Copy file name to clipboardExpand all lines: docs/handlers/subscriptions.md
+17-16Lines changed: 17 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,26 +74,27 @@ Entering `client.listen(...)` sends the request and waits for your acknowledgmen
74
74
75
75
Publishes travel from your handler to the open streams over a `SubscriptionBus`. The default is in-memory: one process, every stream in it. That is the right answer until you run replicas behind a load balancer, because then a client's stream is pinned to one replica, and a publish on another replica has to reach it.
76
76
77
-
With the default bus, it doesn't:
77
+
With the default bus it can't, because every replica has its own:
78
78
79
79
```mermaid
80
-
sequenceDiagram
81
-
participant C as Client
82
-
participant LB as Load balancer
83
-
participant A as Replica A
84
-
participant B as Replica B
85
-
Note over LB: any request,<br/>any replica
86
-
C->>A: subscriptions/listen
87
-
activate A
88
-
A-->>C: acknowledged, stream stays open
89
-
C->>B: tools/call
90
-
Note over B: ctx.notify_* publishes<br/>to B's own bus
91
-
B-->>C: result
92
-
Note over A: hears nothing,<br/>so neither does the client
0 commit comments