@procedures/client 0.18.0 → 0.18.1

package/CHANGELOG.md

@@ -1,5 +1,38 @@
 # @procedures/client
 
+## 0.18.1
+
+### Patch Changes
+
+- d69c8cb: A host that serves a plain collection `a.b` and a collection `a` with partitions fails at registration. To correct it, rename the plain collection. Before, the two had the same topic `collections.a.b`. Thus the readers of `a.b` got the events of the tenant `b` of `a`, a leak across tenants (roadmap CLI-57, decision D23).
+  
+  - The refusal is the new export `CollectionTopicCollisionError`. It names the two collections, the partition and the topic.
+  - `useStorage`, `useStorages`, the option `collections` of a host and `usePartitions` do the check. The check finds the pair in each order, also when the registrations come at different times.
+  - The check also refuses a deeper name, for example `a.b.c` next to `a` with partitions: `b.c` is a partition of `a`.
+  - The check also refuses a storage of `a.b` for the calls without a partition while `a` has partitions, also when `a.b` has partitions. That storage publishes on `collections.a.b`.
+  - A name without a dot does not change. A dotted name without a partitioned prefix does not change. Two collections with partitions, for example `a` and `a.b`, do not change, because the partitions of `a.b` encode its name.
+  
+  PATCH (decision D23): the change refuses only a configuration that leaks events across tenants, so no caller can rely on it. Each correct configuration behaves as before.
+  
+  Migration steps:
+  
+  - When a host fails with `CollectionTopicCollisionError`, rename the plain collection, for example `a.b` to `a_b`. A name without a dot has no topic of a partition.
+  - The site: no change is necessary. It serves no collection.
+  - MiniMongo: no change is necessary. Its server serves no collection.
+  - Graph: no change is necessary. Its host gives partitions to each served collection (`examples`), and no collection has a plain storage.
+  - jarvis: no change is necessary. Its host serves no collection.
+- 0379278: Docs and tests: the rule of the retryable flag of an in-band end (CLI-58). The behavior does not change, thus this change is a PATCH of the client group (decision D13).
+  
+  - Before the stream starts, an error of a handler without a retryable flag gets the flag of its code in `ERROR_CODES` (CLI-48). Thus `UNAVAILABLE` without a flag is retryable, and the HTTP face answers 503.
+  - After the stream starts, an error ends the stream in-band. The in-band end is the `error` line of NDJSON, the `error` frame of WebSocket or the `_meta` of the MCP result.
+  - An in-band end without a retryable flag gets `retryable: false`, also when the stream gave no item. The reader can have items, and a retry can send them again.
+  - A handler gives `retryable: true` when a retry is safe. Then the in-band end is retryable too.
+  - The retry middleware of the client does not retry after an item reached the reader. Thus after the first item, the flag only tells the application.
+  - This rule agrees with the rule of a cut (CLI-48): the flag is false when the call can have had its effect.
+  - `WIRE-PROTOCOL.md` gives the rule in the section "Error codes". Tests pin it on the wire of HTTP and WebSocket, and on the HTTP, WebSocket and MCP faces of the procedures host.
+  
+  The site, MiniMongo, Graph and jarvis: no change.
+
 ## 0.18.0
 
 ### Minor Changes