cross-tab-worker-databus 0.21.31 → 0.21.32

package/CHANGELOG.md

@@ -1,3 +1,31 @@
+## [0.21.32] - 2026-09-25
+
+A delivery bug, found while looking for something else. A topic's **first** publication from a tab that held a matching wildcard was dispatched locally and never forwarded, even while a live durable route named a different owner for it — and delivery is at-most-once, so that publication was gone for good. The fix is a deletion: the memo that made the decision decided nothing.
+
+### Fixed
+
+- **Routing: a topic's first `publish()` / `publishBatch()` now reaches that topic's concrete owner.** Both methods carried a textually identical fast path: while `wildcardPublishCache` held no entry for a topic, it scanned the local wildcard patterns and, on a match, addressed the control frame to *this* worker without consulting the durable route — while every later publication for the same topic did consult it. Measured with one runtime holding `chat.*` and a peer concretely owning `chat.room.1` (both `isAssigned` true, the route record naming the peer): three publications from the wildcard holder landed `1,0,0` on the sender and `0,1,1` on the owner. The first never left the tab. The same shape reproduced for a two-item batch, whose frame the receiver unpacks per item.
+- **This is `0.20.58` from the other side, which is why an eviction rule would not have fixed it.** There, a cached `null` short-circuited the owner lookup and the fix was to keep consulting the route; here a cache *miss* did the same thing. The stored value decided nothing either way — `pattern` and `null` were both read only as "have I scanned this topic" — so the memo is removed rather than bounded, and every non-owned publication now resolves its target through `resolvePublishTarget()`. Wildcard ownership is still honoured: with no live concrete route that call answers with this worker, and the receiving ownership gate matches the pattern. Removing the map also retires the unbounded growth documented in `0.21.31`; that growth was a side effect of this fast path, not a separate defect, so the eviction rule it was framed as needing is no longer needed at all.
+
+- **Repository tooling: a scratch directory inside the linted tree made `pnpm lint` red without naming any product code.** A mutation-probe harness was written to `.gate-logs/` — in-tree on purpose, since `/tmp` had evicted a failing log mid-session and `pnpm test:coverage` deletes `coverage/`, where logs had also been written — and `eslint .` reported 9 errors from it (`no-undef` on `console`/`process`, `no-control-regex`) as a lint failure of the release tree. `.gate-logs/` is now ignored by both git and eslint, with the reason recorded beside the entry in `.gitignore`. `tests/regression.test.ts`'s "keeps scripts/ covered by ESLint" still passes, so the release tooling stays linted and only scratch is excluded.
+
+### Tests
+
+- **Two regressions, one per entry point, each asserted one publication at a time** so a regression names *which* publication was lost instead of reporting a count short by one: `forwards a topic's FIRST publish to its concrete remote owner, not to a matching local wildcard` and `forwards a batch's FIRST publish to the concrete remote owner as well`. Measured both ways — without the fix they fail at `first publish must reach the concrete owner: expected +0 to be 1` and `expected [] to deeply equal [1, 2]`; with it the file is green. Three pre-existing cases that named the removed cache in their titles were retitled to what they actually assert, and the single-runtime pair among them is now labelled as the characterization it is: a lone runtime always wins its own election, so it cannot distinguish the two paths.
+- **`trace.ts`'s flush-activity guard was re-measured on the tree that shipped this fix**, not carried forward: deleting `received` alone reddens 3 tests, `dispatched` 2, `dedupAccepted` 1, `dedupSuppressed` 1 — each operand's own kill set, all four restorations byte-identical.
+
+### Documentation
+
+- **`trace.ts`: each kill now names the file it comes from.** The note recorded which test dies to each operand deletion but not where it lives, and the two `dispatched` kills sit in two different files (`tests/data-bus.test.ts` and `tests/trace.test.ts`).
+- **The publication-lag samples were extended, and one of them had been undercounted.** `0.21.31`'s tag run is the first to exercise the raised 720 s published-consumer ceiling: green on attempt 1 at 308 s, with its registry record 127.2 s after the publish ack and the remaining ~181 s spent against the cache lifetime — so the 310 s maximum the ceiling is sized from still stands, and the ceiling does not need raising again. The other half of that sentence was wrong in the cheap direction: the checklist and `AGENTS.md` credited the 304–305 s regularity to "three consecutive green tag runs", where the five runs from 0.21.25 to 0.21.29 took 307, 304, 305, 304 and 304 s, six samples in a 5-second band once 0.21.31's 308 s is counted. The lag list, the run-by-run durations and the `gh api` lookup that re-derives both are now written out in `docs/release-checklist.md` (en + zh), the workflow's own comment, and `tests/workflows.test.ts`.
+- **`docs/architecture.md` (en + zh): the wildcard publish memo is removed, not capped.** Both copies had described it as the per-topic map the documented `knownTopics` cap does not reach, with an open question about which of its two value shapes could be forgotten; neither half survives, so the paragraph now says what replaced it and records the 1,200-versus-500 measurement beside the delivery counts that made the mechanism visible.
+- **`publish()`'s surviving comment described the deleted mechanism.** Above the `assignedTopics.has(topicKey)` early return it still said wildcard holders "use the same fast path" — which that lookup never did: `assignedTopics` is keyed by the plaintext it was handed, so a holder of `chat.*` carries the *pattern's* key and a concrete topic misses the `has()`, exactly the fall-through the fix relies on. The sentence now names which lookup answers for which assignment, checked against `isAssigned()`'s own `topicMatchesPattern` loop and against `publishBatch()`, which carried no such claim.
+- **The upstream-blocked toolchain item was re-checked, and both channels still exclude TypeScript 7.** `typescript-eslint`'s latest (8.70.1) and its canary (8.70.2-alpha.7) both declare `typescript >=4.8.4 <6.1.0`, so TS 7.0.2 would break the lint gate before touching our own types. The roadmap entry now says how to look that up without being fooled: read `dist-tags.canary`, because sorting version strings puts `8.9.1-alpha.9` last — `9` sorts after `70` — while the line actually worth watching is 8.70.x. The English entry's date had also drifted from the Chinese one (2026-09-23 against 2026-09-22) for the same check; both now carry one date and the same two versions.
+
+### Compatibility
+
+One behavioural change: a first publication for a wildcard-covered topic that has a live concrete owner is now forwarded to that owner instead of being dispatched locally. No export, option, default, frame or storage key changed; `wildcardPublishCache` was a private field and is absent from the emitted `dist/core/cluster.d.ts`. `verify:compat`, `verify:types` and `verify:pack` run against `v0.21.31`.
+
 ## [0.21.31] - 2026-09-25
 
 The `0.21.30` tag run failed its blocking published-consumer gate after a *successful* publish. Diagnosing that gave the retry budget a measured size, retired a floor in the gate whose job was to keep that failure out, and retracted a note this repository wrote about the same failure less than an hour before it was corrected. No library code changed.

package/dist/centrifuge.js

@@ -7,7 +7,7 @@ import {
   publicationMetadata,
   selectWorkerBackend,
   serializeError
-} from "./chunk-M4RO3MVX.js";
+} from "./chunk-PNEOQX4O.js";
 import {
   CENTRIFUGE_INPUT_TYPE,
   CENTRIFUGE_OUTPUT_TYPE,

package/dist/{chunk-M4RO3MVX.js → chunk-PNEOQX4O.js}

@@ -672,19 +672,6 @@ var WorkerClusterRuntime = class {
       this.routeOwnerCache.delete(oldest);
     }
   }
-  // Concrete topic → the local wildcard pattern that matched it, or `null` for
-  // "scanned, nothing matched". UNLIKE the reverse cache below, this map has no cap:
-  // it grows one entry per distinct topic this worker publishes, and is cleared only
-  // on the two lifecycle teardowns whose `routeOwnerCache.clear()` sits beside each
-  // `wildcardPublishCache.clear()`. Measured: 1,200 `publish()` calls on distinct
-  // topic names leave `knownTopics` at its 500-entry cap and this map holding 1,200.
-  // A cap is not free here, because both halves decide something. Evicting a pattern
-  // re-runs the first local dispatch the entry exists to prevent. Evicting a `null`
-  // re-scans, and if a wildcard was assigned in the meantime that publication
-  // dispatches locally instead of routing by owner — the fan-out a first publication
-  // gets. So bounding this map needs a rule about which of the two may be forgotten,
-  // not a number; until one is chosen the growth is the honest cost of the memo.
-  wildcardPublishCache = /* @__PURE__ */ new Map();
   // Reverse mapping: opaque topicKey → plaintext topic. A bounded cache with
   // FIFO eviction — NOT authoritative. It can hold a topicKey that is also in
   // assignedTopics (the owned guard prevents evicting those), because it is
@@ -761,7 +748,6 @@ var WorkerClusterRuntime = class {
     this.subscribedTopics.clear();
     this.assignedTopics.clear();
     this.routeOwnerCache.clear();
-    this.wildcardPublishCache.clear();
     this.knownTopics.clear();
     this.suspended = false;
   }
@@ -829,7 +815,6 @@ var WorkerClusterRuntime = class {
     this.handoffAssignedTopics();
     this.assignedTopics.clear();
     this.routeOwnerCache.clear();
-    this.wildcardPublishCache.clear();
     this.removeStorage(this.workerStorageKey(this.workerId));
     this.flushStorage();
     this.notifyRegistry();
@@ -936,16 +921,6 @@ var WorkerClusterRuntime = class {
     if (this.assignedTopics.has(topicKey)) {
       return this.sendControl(this.workerId, CONTROL_ACTION.PUBLISH, topic, topicKey, data, metadata);
     }
-    const cachedPattern = this.wildcardPublishCache.get(topic);
-    if (cachedPattern === void 0) {
-      for (const pattern of this.assignedTopics.values()) {
-        if (pattern !== topic && topicMatchesPattern(pattern, topic)) {
-          this.wildcardPublishCache.set(topic, pattern);
-          return this.sendControl(this.workerId, CONTROL_ACTION.PUBLISH, topic, topicKey, data, metadata);
-        }
-      }
-      this.wildcardPublishCache.set(topic, null);
-    }
     return this.sendControl(this.resolvePublishTarget(topic, topicKey), CONTROL_ACTION.PUBLISH, topic, topicKey, data, metadata);
   }
   /**
@@ -970,17 +945,6 @@ var WorkerClusterRuntime = class {
       this.dispatchLocalPublishBatch(topic, topicKey, items);
       return true;
     }
-    const cachedPattern = this.wildcardPublishCache.get(topic);
-    if (cachedPattern === void 0) {
-      for (const pattern of this.assignedTopics.values()) {
-        if (pattern !== topic && topicMatchesPattern(pattern, topic)) {
-          this.wildcardPublishCache.set(topic, pattern);
-          this.dispatchLocalPublishBatch(topic, topicKey, items);
-          return true;
-        }
-      }
-      this.wildcardPublishCache.set(topic, null);
-    }
     const target = this.resolvePublishTarget(topic, topicKey);
     if (target === this.workerId) {
       this.dispatchLocalPublishBatch(topic, topicKey, items);
@@ -2511,7 +2475,7 @@ var SDK_VERSION = (
   // declaration's type is `string | undefined` and the export's is `string`
   // (dropping the conditional is TS2322, measured). Recorded here so the leg reads
   // as a shape the harness cannot reach rather than as a case nobody exercised.
-  true ? "0.21.31" : ""
+  true ? "0.21.32" : ""
 );
 
 // src/core/data-bus.ts
@@ -3751,4 +3715,4 @@ export {
   parseDataBusPublication,
   selectWorkerBackend
 };
-//# sourceMappingURL=chunk-M4RO3MVX.js.map
+//# sourceMappingURL=chunk-PNEOQX4O.js.map