cross-tab-worker-databus 0.21.30 → 0.21.31
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +23 -0
- package/dist/centrifuge.js +1 -1
- package/dist/{chunk-ESJJV7F4.js → chunk-M4RO3MVX.js} +14 -2
- package/dist/chunk-M4RO3MVX.js.map +7 -0
- package/dist/cjs/centrifuge.cjs +13 -1
- package/dist/cjs/centrifuge.cjs.map +2 -2
- package/dist/cjs/index.cjs +13 -1
- package/dist/cjs/index.cjs.map +2 -2
- package/dist/core/cluster.d.ts.map +1 -1
- package/dist/core/trace.d.ts.map +1 -1
- package/dist/index.js +1 -1
- package/docs/architecture.md +2 -0
- package/docs/release-checklist.md +4 -2
- package/docs/roadmap.md +11 -2
- package/docs/zh/architecture.md +2 -0
- package/docs/zh/release-checklist.md +4 -2
- package/docs/zh/roadmap.md +11 -2
- package/package.json +1 -1
- package/dist/chunk-ESJJV7F4.js.map +0 -7
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,26 @@
|
|
|
1
|
+
## [0.21.31] - 2026-09-25
|
|
2
|
+
|
|
3
|
+
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.
|
|
4
|
+
|
|
5
|
+
### Fixed
|
|
6
|
+
|
|
7
|
+
- **Release tooling: the published-consumer retry ceiling sat below the propagation lag it exists to absorb.** `PUBLISHED_VERIFY_ATTEMPTS=48` × 7500 ms is 360 s, and the 0.21.30 tag run consumed all of it on `ETARGET` while that version's tarball was already fetchable; the re-run against the unchanged tag then passed in 1 s. Two measured terms now size the number. (1) `npm publish`'s success ack precedes the registry's own `time[<version>]` record — by 74.8 s on 0.21.29, 96.8 s on 0.21.28, 248.7 s on 0.21.27 and 310.0 s on 0.21.30. (2) The packument that `npm pack` resolves against is served `cache-control: public, max-age=300`, so a copy of it anywhere in the path may be a full cache lifetime stale by design; that term is also what the three preceding green tag runs were reporting when they consumed 305 s, 304 s and 304 s of the ceiling in turn. The budget is now 96 × 7500 ms = 720 s, clearing the 310 + 300 = 610 s the two add to. Which copy served this run's stale views is **not** established: a purely npm-local-cache account predicts the retry should have waited for the same 300 s object and it did not, so the comment records the open question instead of naming a cache.
|
|
8
|
+
- **`tests/workflows.test.ts` pinned a floor that the value which just failed satisfied.** The assertion was `totalMs >= 5 * 60 * 1000`, so the 360 s budget that had just turned a good release red passed the gate whose entire purpose is to stop that happening, and nothing would have objected to lowering it again. The floor is now the sum above, written as two named constants beside the rule that re-derives each. Measured against it: setting the workflow's attempts from 96 back to 48 fails exactly that test, and both the 360 s budget that failed here and the 120 s one 0.20.89 exhausted are rejected by it.
|
|
9
|
+
|
|
10
|
+
### Documentation
|
|
11
|
+
|
|
12
|
+
- **`cluster.ts`: the one per-topic map the documented `knownTopics` cap does not cover now says so.** `wildcardPublishCache` — concrete topic → the local wildcard pattern that matched it, or `null` for "scanned, nothing matched" — has no cap, and is cleared only by the two lifecycle teardowns whose `wildcardPublishCache.clear()` sits beside each `routeOwnerCache.clear()`. Measured: 1,200 `publish()` calls on distinct topic names leave `knownTopics` at its 500-entry cap while this map holds 1,200. The note records why a number is not the fix — evicting a *pattern* re-runs the first local dispatch the entry exists to prevent, while evicting a `null` re-scans and, if a wildcard has been assigned in between, gives that publication the fan-out of a first one — so bounding the map needs a rule about which of the two halves may be forgotten. `docs/architecture.md` and its Chinese counterpart gained the same statement in the paragraph after "Cap and eviction", which is where a reader looking for the memory bound would look.
|
|
13
|
+
- **`trace.ts`: the metrics guard's kill sets are named by test instead of counted.** Its flush-activity note carried "(three cases for `received`, two for `dispatched`)". Those multiplicities are exactly the kind that go false on an unrelated commit, and the five verbatim test names now stand in their place — including the fact the count hid, that `dispatched`'s two cases live in two different files.
|
|
14
|
+
- **`docs/release-checklist.md` (en + zh): how to adjudicate a publish, plus one retraction.** The note written during the same release claimed the package document endpoint and the tarball URL had disagreed "in the same minute". Its own timestamps say otherwise: the stale-document read was 21:43:15Z and the registry's record of that version is 21:44:12.987Z, so the read was not lagging an artifact that already existed — it was correctly reporting a publish the registry had not finished writing. The corrected text gives the sequence with its clock readings, states that absence from `versions`/`latest` minutes after a green publish step is the *expected* state of a successful release, names the genuine disagreement (a HEAD and a pack from one machine good by 21:44:35Z while the runner was still on `ETARGET` at 21:45:07Z), and tells the reader to probe from the machine that is failing. The "twelve times the manual default / ~6-minute ceiling / expect ~39 retries of 48" budget prose is replaced by the derivation above, with the two lookups needed to re-measure it.
|
|
15
|
+
|
|
16
|
+
### Tests
|
|
17
|
+
|
|
18
|
+
- **`tests/version-compat.test.ts` got its own per-test ceiling, because the global one was load-dependent for that file alone.** Every case there builds a throwaway git repository and runs `scripts/verify-version-compat.mjs` as a child process — `git init`, `git add`, `git commit`, `git tag` and one `node` spawn per test — so a case costs five process starts plus temp-tree I/O, not the object comparison it asserts on. Measured on an 8-core host at load average 400+: under `pnpm test:coverage` with nothing else of ours running, one case died with `Error: Test timed out in 15000ms` while 940 of 941 passed; the same file alone with a competing `pnpm bench` on the machine lost two cases and reported 3–19 s for the survivors (that reading is confounded by the concurrency and is the slowest of the three); and the same file alone with the contention gone passed all 18 in 23.7 s total, about 1.3 s per case. Which case crossed the line moved between runs, which is the signature of scheduling rather than of a hang. The ceiling is therefore raised for this file only, leaving every in-process test on the global 15 s. Proven wired rather than assumed: setting the value to `1` makes 17 of the 18 cases fail with `Test timed out in 1ms` and the run exit 1 — a control that could not fail would say nothing about whether the call binds.
|
|
19
|
+
|
|
20
|
+
### Compatibility
|
|
21
|
+
|
|
22
|
+
No library code, export, frame, option, default or storage key changed; `verify:compat`, `verify:types` and `verify:pack` pass against `v0.21.30`. The behavioural changes are confined to `.github/workflows/release.yml`, `tests/workflows.test.ts` and `tests/version-compat.test.ts`, none of which ships inside the package; the workflow change takes effect on the next tag push.
|
|
23
|
+
|
|
1
24
|
## [0.21.30] - 2026-09-25
|
|
2
25
|
|
|
3
26
|
The claim queue's remaining sites, worked one measurement at a time. Two shipped absolutes turned out to be false, four counts were made re-derivable where they had only been asserted, and one release gate was found able to pass while verifying the wrong artifact. No library code changed.
|
package/dist/centrifuge.js
CHANGED
|
@@ -672,6 +672,18 @@ var WorkerClusterRuntime = class {
|
|
|
672
672
|
this.routeOwnerCache.delete(oldest);
|
|
673
673
|
}
|
|
674
674
|
}
|
|
675
|
+
// Concrete topic → the local wildcard pattern that matched it, or `null` for
|
|
676
|
+
// "scanned, nothing matched". UNLIKE the reverse cache below, this map has no cap:
|
|
677
|
+
// it grows one entry per distinct topic this worker publishes, and is cleared only
|
|
678
|
+
// on the two lifecycle teardowns whose `routeOwnerCache.clear()` sits beside each
|
|
679
|
+
// `wildcardPublishCache.clear()`. Measured: 1,200 `publish()` calls on distinct
|
|
680
|
+
// topic names leave `knownTopics` at its 500-entry cap and this map holding 1,200.
|
|
681
|
+
// A cap is not free here, because both halves decide something. Evicting a pattern
|
|
682
|
+
// re-runs the first local dispatch the entry exists to prevent. Evicting a `null`
|
|
683
|
+
// re-scans, and if a wildcard was assigned in the meantime that publication
|
|
684
|
+
// dispatches locally instead of routing by owner — the fan-out a first publication
|
|
685
|
+
// gets. So bounding this map needs a rule about which of the two may be forgotten,
|
|
686
|
+
// not a number; until one is chosen the growth is the honest cost of the memo.
|
|
675
687
|
wildcardPublishCache = /* @__PURE__ */ new Map();
|
|
676
688
|
// Reverse mapping: opaque topicKey → plaintext topic. A bounded cache with
|
|
677
689
|
// FIFO eviction — NOT authoritative. It can hold a topicKey that is also in
|
|
@@ -2499,7 +2511,7 @@ var SDK_VERSION = (
|
|
|
2499
2511
|
// declaration's type is `string | undefined` and the export's is `string`
|
|
2500
2512
|
// (dropping the conditional is TS2322, measured). Recorded here so the leg reads
|
|
2501
2513
|
// as a shape the harness cannot reach rather than as a case nobody exercised.
|
|
2502
|
-
true ? "0.21.
|
|
2514
|
+
true ? "0.21.31" : ""
|
|
2503
2515
|
);
|
|
2504
2516
|
|
|
2505
2517
|
// src/core/data-bus.ts
|
|
@@ -3739,4 +3751,4 @@ export {
|
|
|
3739
3751
|
parseDataBusPublication,
|
|
3740
3752
|
selectWorkerBackend
|
|
3741
3753
|
};
|
|
3742
|
-
//# sourceMappingURL=chunk-
|
|
3754
|
+
//# sourceMappingURL=chunk-M4RO3MVX.js.map
|