cross-tab-worker-databus 0.21.32 → 0.21.34
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 +42 -1
- package/dist/centrifuge-session.d.ts.map +1 -1
- package/dist/centrifuge.js +1 -1
- package/dist/centrifuge.js.map +2 -2
- package/dist/centrifuge.shared.worker.js.map +2 -2
- package/dist/centrifuge.worker.js.map +2 -2
- package/dist/{chunk-PNEOQX4O.js → chunk-A3UG46FI.js} +2 -2
- package/dist/chunk-A3UG46FI.js.map +7 -0
- package/dist/cjs/centrifuge.cjs +1 -1
- package/dist/cjs/centrifuge.cjs.map +2 -2
- package/dist/cjs/index.cjs +1 -1
- package/dist/cjs/index.cjs.map +2 -2
- package/dist/core/cluster.d.ts.map +1 -1
- package/dist/core/data-bus.d.ts.map +1 -1
- package/dist/core/hash.d.ts.map +1 -1
- package/dist/core/trace.d.ts.map +1 -1
- package/dist/index.js +1 -1
- package/docs/architecture.md +9 -8
- package/docs/release-checklist.md +2 -2
- package/docs/roadmap.md +24 -6
- package/docs/zh/architecture.md +9 -8
- package/docs/zh/release-checklist.md +2 -2
- package/docs/zh/roadmap.md +24 -6
- package/package.json +1 -1
- package/dist/chunk-PNEOQX4O.js.map +0 -7
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"cluster.d.ts","sourceRoot":"","sources":["../../src/core/cluster.ts"],"names":[],"mappings":"AASA,OAAO,KAAK,EAAkB,kBAAkB,EAAe,MAAM,eAAe,CAAC;AASrF,OAAO,KAAK,EACV,0BAA0B,EAC1B,oBAAoB,EAGpB,mBAAmB,EACnB,YAAY,EAEZ,WAAW,EACX,YAAY,EAEb,MAAM,SAAS,CAAC;AAEjB,OAAO,EAIL,qBAAqB,EAItB,MAAM,oBAAoB,CAAC;AAK5B,0EAA0E;AAC1E,MAAM,WAAW,qBAAqB;IACpC,mFAAmF;IACnF,SAAS,EAAE,CACT,MAAM,EAAE,mBAAmB,EAC3B,KAAK,EAAE,MAAM,EACb,IAAI,CAAC,EAAE,OAAO,EACd,SAAS,CAAC,EAAE,MAAM,EAClB,SAAS,CAAC,EAAE,MAAM,KACf,IAAI,CAAC;IACV;;yEAEqE;IACrE,cAAc,CAAC,EAAE,CACf,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,aAAa,CAAC;QAAE,IAAI,EAAE,OAAO,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC,KAC5E,IAAI,CAAC;IACV,yEAAyE;IACzE,gBAAgB,CAAC,EAAE,CAAC,OAAO,EAAE,OAAO,KAAK,IAAI,CAAC;IAC9C;;;2DAGuD;IACvD,OAAO,EAAE,CACP,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,OAAO,EAChB,cAAc,EAAE,MAAM,EACtB,WAAW,CAAC,EAAE,MAAM,KACjB,IAAI,CAAC;IACV,qDAAqD;IACrD,SAAS,CAAC,EAAE,MAAM,IAAI,CAAC;IACvB,oDAAoD;IACpD,QAAQ,CAAC,EAAE,MAAM,IAAI,CAAC;IACtB,qGAAqG;IACrG,YAAY,CAAC,EAAE,CAAC,KAAK,EAAE;QACrB,SAAS,EAAE,CAAC,OAAO,qBAAqB,CAAC,SAAS,GAAG,OAAO,qBAAqB,CAAC,eAAe,GAAG,OAAO,qBAAqB,CAAC,wBAAwB,CAAC,CAAC;QAC3J,KAAK,EAAE,MAAM,CAAC;KACf,KAAK,IAAI,CAAC;CACZ;AAED,MAAM,WAAW,oBAAoB;IACnC;;;;;;oFAMgF;IAChF,UAAU,EAAE,MAAM,CAAC;IACnB,0EAA0E;IAC1E,QAAQ,EAAE,qBAAqB,CAAC;IAChC,2EAA2E;IAC3E,WAAW,CAAC,EAAE,kBAAkB,CAAC;IACjC,4EAA4E;IAC5E,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,8EAA8E;IAC9E,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,6EAA6E;IAC7E,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,qFAAqF;IACrF,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,2DAA2D;IAC3D,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,iEAAiE;IACjE,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;oCAIgC;IAChC,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B;;;kFAG8E;IAC9E,aAAa,CAAC,EAAE,oBAAoB,CAAC;CACtC;AAED,2EAA2E;AAC3E,MAAM,WAAW,qBAAqB;IACpC,eAAe,EAAE,MAAM,CAAC;IACxB,2FAA2F;IAC3F,oBAAoB,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC,CAAC;IACpD,WAAW,EAAE,OAAO,CAAC;IACrB,SAAS,EAAE,OAAO,CAAC;IACnB,aAAa,EAAE,YAAY,CAAC;IAC5B,OAAO,EAAE,YAAY,EAAE,CAAC;IACxB,qFAAqF;IACrF,MAAM,EAAE,KAAK,CAAC,WAAW,GAAG;QAAE,KAAK,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,CAAC,CAAC;IACtD,gBAAgB,EAAE,MAAM,EAAE,CAAC;IAC3B,cAAc,EAAE,MAAM,EAAE,CAAC;IACzB,0DAA0D;IAC1D,WAAW,EAAE,KAAK,CAAC;QAAE,QAAQ,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IACxD,eAAe,CAAC,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,MAAM,CAAA;KAAE,CAAC;CAC/E;
|
|
1
|
+
{"version":3,"file":"cluster.d.ts","sourceRoot":"","sources":["../../src/core/cluster.ts"],"names":[],"mappings":"AASA,OAAO,KAAK,EAAkB,kBAAkB,EAAe,MAAM,eAAe,CAAC;AASrF,OAAO,KAAK,EACV,0BAA0B,EAC1B,oBAAoB,EAGpB,mBAAmB,EACnB,YAAY,EAEZ,WAAW,EACX,YAAY,EAEb,MAAM,SAAS,CAAC;AAEjB,OAAO,EAIL,qBAAqB,EAItB,MAAM,oBAAoB,CAAC;AAK5B,0EAA0E;AAC1E,MAAM,WAAW,qBAAqB;IACpC,mFAAmF;IACnF,SAAS,EAAE,CACT,MAAM,EAAE,mBAAmB,EAC3B,KAAK,EAAE,MAAM,EACb,IAAI,CAAC,EAAE,OAAO,EACd,SAAS,CAAC,EAAE,MAAM,EAClB,SAAS,CAAC,EAAE,MAAM,KACf,IAAI,CAAC;IACV;;yEAEqE;IACrE,cAAc,CAAC,EAAE,CACf,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,aAAa,CAAC;QAAE,IAAI,EAAE,OAAO,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC,KAC5E,IAAI,CAAC;IACV,yEAAyE;IACzE,gBAAgB,CAAC,EAAE,CAAC,OAAO,EAAE,OAAO,KAAK,IAAI,CAAC;IAC9C;;;2DAGuD;IACvD,OAAO,EAAE,CACP,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,OAAO,EAChB,cAAc,EAAE,MAAM,EACtB,WAAW,CAAC,EAAE,MAAM,KACjB,IAAI,CAAC;IACV,qDAAqD;IACrD,SAAS,CAAC,EAAE,MAAM,IAAI,CAAC;IACvB,oDAAoD;IACpD,QAAQ,CAAC,EAAE,MAAM,IAAI,CAAC;IACtB,qGAAqG;IACrG,YAAY,CAAC,EAAE,CAAC,KAAK,EAAE;QACrB,SAAS,EAAE,CAAC,OAAO,qBAAqB,CAAC,SAAS,GAAG,OAAO,qBAAqB,CAAC,eAAe,GAAG,OAAO,qBAAqB,CAAC,wBAAwB,CAAC,CAAC;QAC3J,KAAK,EAAE,MAAM,CAAC;KACf,KAAK,IAAI,CAAC;CACZ;AAED,MAAM,WAAW,oBAAoB;IACnC;;;;;;oFAMgF;IAChF,UAAU,EAAE,MAAM,CAAC;IACnB,0EAA0E;IAC1E,QAAQ,EAAE,qBAAqB,CAAC;IAChC,2EAA2E;IAC3E,WAAW,CAAC,EAAE,kBAAkB,CAAC;IACjC,4EAA4E;IAC5E,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,8EAA8E;IAC9E,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,6EAA6E;IAC7E,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,qFAAqF;IACrF,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,2DAA2D;IAC3D,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,iEAAiE;IACjE,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;oCAIgC;IAChC,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B;;;kFAG8E;IAC9E,aAAa,CAAC,EAAE,oBAAoB,CAAC;CACtC;AAED,2EAA2E;AAC3E,MAAM,WAAW,qBAAqB;IACpC,eAAe,EAAE,MAAM,CAAC;IACxB,2FAA2F;IAC3F,oBAAoB,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC,CAAC;IACpD,WAAW,EAAE,OAAO,CAAC;IACrB,SAAS,EAAE,OAAO,CAAC;IACnB,aAAa,EAAE,YAAY,CAAC;IAC5B,OAAO,EAAE,YAAY,EAAE,CAAC;IACxB,qFAAqF;IACrF,MAAM,EAAE,KAAK,CAAC,WAAW,GAAG;QAAE,KAAK,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,CAAC,CAAC;IACtD,gBAAgB,EAAE,MAAM,EAAE,CAAC;IAC3B,cAAc,EAAE,MAAM,EAAE,CAAC;IACzB,0DAA0D;IAC1D,WAAW,EAAE,KAAK,CAAC;QAAE,QAAQ,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IACxD,eAAe,CAAC,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,MAAM,CAAA;KAAE,CAAC;CAC/E;AAaD;;;;;;;;;;;;;;;GAeG;AACH,qBAAa,oBAAoB;IAC/B,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAE1B,OAAO,CAAC,QAAQ,CAAC,WAAW,CAAqB;IACjD,OAAO,CAAC,QAAQ,CAAC,QAAQ,CAAwB;IACjD,OAAO,CAAC,OAAO,CAAqB;IACpC,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAS;IAC1C,OAAO,CAAC,QAAQ,CAAC,mBAAmB,CAAS;IAC7C,OAAO,CAAC,QAAQ,CAAC,WAAW,CAAS;IACrC,OAAO,CAAC,QAAQ,CAAC,YAAY,CAAS;IACtC,OAAO,CAAC,QAAQ,CAAC,WAAW,CAAS;IACrC,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAS;IAC1C,OAAO,CAAC,QAAQ,CAAC,WAAW,CAAS;IACrC,mFAAmF;IACnF,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAmC;IACjE,gFAAgF;IAChF,OAAO,CAAC,gBAAgB,CAItB;IAEF,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAqB;IAKtD,OAAO,CAAC,QAAQ,CAAC,cAAc,CAA6B;IAC5D,OAAO,CAAC,QAAQ,CAAC,eAAe,CAA+D;IAC/F,OAAO,CAAC,QAAQ,CAAC,kBAAkB,CAAS;IAC5C,OAAO,CAAC,mBAAmB,CAAK;IAChC,OAAO,CAAC,qBAAqB,CAAK;IAClC,OAAO,CAAC,mBAAmB,CAAK;IAChC,OAAO,CAAC,sBAAsB,CAAuB;IACrD,OAAO,CAAC,oBAAoB;IAoB5B,OAAO,CAAC,QAAQ,CAAC,WAAW,CAA6B;IACzD,OAAO,CAAC,OAAO,CAA+B;IAC9C,OAAO,CAAC,eAAe,CAAiB;IACxC,OAAO,CAAC,OAAO,CAAS;IACxB,OAAO,CAAC,SAAS,CAAS;IAC1B,OAAO,CAAC,kBAAkB,CAAS;IACnC;4EACwE;IACxE,OAAO,CAAC,mBAAmB,CAAK;IAChC,OAAO,CAAC,aAAa,CAAe;gBAExB,OAAO,EAAE,oBAAoB;IAsCzC,sFAAsF;IACtF,KAAK,IAAI,IAAI;IAiBb;;;;;;OAMG;IACH,IAAI,IAAI,IAAI;IAuCZ;;;OAGG;IACH,OAAO,CAAC,QAAQ;IAoGhB;;;OAGG;IACH,OAAO,CAAC,KAAK;IA+Eb,oEAAoE;IACpE,SAAS,CAAC,MAAM,EAAE,YAAY,GAAG,IAAI;IAMrC;;;;OAIG;IACH,SAAS,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO;IA0CjC;;;OAGG;IACH,WAAW,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI;IAOhC;;yEAEqE;IACrE,OAAO,CAAC,mBAAmB;IAa3B,qGAAqG;IACrG,OAAO,CAAC,qBAAqB;IAsF7B;;;;;OAKG;IACH,OAAO,CAAC,KAAK,EAAE,MAAM,EAAE,IAAI,EAAE,OAAO,EAAE,SAAS,CAAC,EAAE,MAAM,GAAG,OAAO;IAClE,OAAO,CAAC,KAAK,EAAE,MAAM,EAAE,IAAI,EAAE,OAAO,EAAE,QAAQ,CAAC,EAAE,0BAA0B,GAAG,OAAO;IA2CrF;;;;;;OAMG;IACH,YAAY,CACV,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,aAAa,CAAC;QAAE,IAAI,EAAE,OAAO,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAC;QAAC,SAAS,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC,GAC9E,OAAO;IAwCV;sFACkF;IAClF,OAAO,CAAC,oBAAoB;IA6B5B,iEAAiE;IACjE,OAAO,CAAC,oBAAoB;IAa5B;6EACyE;IACzE,OAAO,CAAC,yBAAyB;IAYjC;;;mEAG+D;IAC/D,OAAO,CAAC,gBAAgB;IAIxB;;iFAE6E;IAC7E,cAAc,CAAC,SAAS,EAAE,MAAM,EAAE,OAAO,EAAE,OAAO,EAAE,WAAW,CAAC,EAAE,MAAM,GAAG,IAAI;IAS/E;2CACuC;IACvC,OAAO,CAAC,aAAa;IAMrB;;+DAE2D;IAC3D,OAAO,CAAC,gBAAgB;IAyBxB,UAAU,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO;IA2BlC,4EAA4E;IAC5E,cAAc,IAAI,OAAO;IAIzB;8EAC0E;IAC1E,OAAO,CAAC,aAAa;IAMrB;kEAC8D;IAC9D,kBAAkB,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO;IAQ1C,iEAAiE;IACjE,sBAAsB,IAAI;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE;IAEpE,8EAA8E;IAC9E,WAAW,IAAI,qBAAqB;IAuBpC,OAAO,CAAC,QAAQ,CAAC,cAAc,CAAsB;IAErD,OAAO,CAAC,QAAQ,CAAC,cAAc,CAU7B;IAEF,OAAO,CAAC,QAAQ,CAAC,sBAAsB,CAQrC;IAEF,OAAO,CAAC,qBAAqB;IAQ7B,OAAO,CAAC,wBAAwB;IAyBhC,qFAAqF;IACrF,OAAO,CAAC,QAAQ,CAAC,aAAa,CAsB5B;IAEF,mFAAmF;IACnF,OAAO,CAAC,oBAAoB;IAoF5B;;;;;;;OAOG;IACH,OAAO,CAAC,2BAA2B;IAYnC;kEAC8D;IAC9D,OAAO,CAAC,iBAAiB;IAgBzB;;;;OAIG;IACH,OAAO,CAAC,0BAA0B;IAoBlC;;;;oCAIgC;IAChC,OAAO,CAAC,mBAAmB;IAW3B;;;;oEAIgE;IAChE,OAAO,CAAC,cAAc;IAItB,8EAA8E;IAC9E,OAAO,CAAC,SAAS;IAkCjB;;iFAE6E;IAC7E,OAAO,CAAC,gBAAgB;IASxB;;;;;;;;OAQG;IACH,OAAO,CAAC,sBAAsB;IA2F9B;;;;;;;;;;;;;;;;;;;;;;;;;;OA0BG;IACH,OAAO,CAAC,2BAA2B;IAqCnC,wEAAwE;IACxE,OAAO,CAAC,uBAAuB;IAa/B;;;;OAIG;IACH,OAAO,CAAC,WAAW;IA6CnB,oFAAoF;IACpF,OAAO,CAAC,IAAI;IAUZ,qFAAqF;IACrF,OAAO,CAAC,WAAW;IAenB,0EAA0E;IAC1E,OAAO,CAAC,oBAAoB;IAsB5B;;;qEAGiE;IACjE,OAAO,CAAC,SAAS;IAKjB;;;yCAGqC;IACrC,OAAO,CAAC,eAAe;IAavB,2EAA2E;IAC3E,OAAO,CAAC,UAAU;IA8BlB;;qCAEiC;IACjC,OAAO,CAAC,gBAAgB;IAgBxB,yFAAyF;IACzF,OAAO,CAAC,YAAY;IAYpB,8EAA8E;IAC9E,OAAO,CAAC,qBAAqB;IAU7B,oEAAoE;IACpE,OAAO,CAAC,0BAA0B;IAQlC,8DAA8D;IAC9D,OAAO,CAAC,eAAe;IAQvB;;;;;;mCAM+B;IAC/B,OAAO,CAAC,WAAW;IAYnB,4EAA4E;IAC5E,OAAO,CAAC,cAAc;IAItB,8GAA8G;IAC9G,OAAO,CAAC,WAAW;IAOnB,kGAAkG;IAClG,OAAO,CAAC,UAAU;IAqBlB;;;;;;;;;;;;;;;OAeG;IACH,OAAO,CAAC,aAAa;IAmCrB,OAAO,CAAC,gBAAgB;IAIxB,OAAO,CAAC,eAAe;IAIvB,OAAO,CAAC,oBAAoB;IAI5B,OAAO,CAAC,aAAa;IAQrB,8EAA8E;IAC9E,OAAO,CAAC,YAAY;CAGrB"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"data-bus.d.ts","sourceRoot":"","sources":["../../src/core/data-bus.ts"],"names":[],"mappings":"AAQA,OAAO,KAAK,EAAE,oBAAoB,EAAE,qBAAqB,EAAE,MAAM,WAAW,CAAC;AAE7E,OAAO,KAAK,EACV,mBAAmB,EAEnB,qBAAqB,EACrB,qBAAqB,EACrB,oBAAoB,EACpB,gBAAgB,EAChB,YAAY,EACb,MAAM,SAAS,CAAC;AAEjB,OAAO,KAAK,EAAE,sBAAsB,EAAE,mBAAmB,EAAE,MAAM,SAAS,CAAC;AAC3E,OAAO,KAAK,EAAE,wBAAwB,EAAE,MAAM,sBAAsB,CAAC;AAGrE,OAAO,KAAK,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,iBAAiB,CAAC;AAE9E,OAAO,EAGL,cAAc,EACd,YAAY,EAEZ,cAAc,EAUf,MAAM,oBAAoB,CAAC;AAQ5B;;wBAEwB;AACxB;;;;mBAImB;AACnB,MAAM,WAAW,oBAAoB,CAAC,KAAK,GAAG,OAAO;IACnD;;;sBAGkB;IAClB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,oEAAoE;IACpE,WAAW,CAAC,EAAE,wBAAwB,CAAC,KAAK,CAAC,CAAC;IAC9C,oEAAoE;IACpE,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;qEAIiE;IACjE,aAAa,CAAC,EAAE,CAAC,OAAO,cAAc,CAAC,CAAC,MAAM,OAAO,cAAc,CAAC,CAAC;IACrE,sEAAsE;IACtE,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,wEAAwE;IACxE,gBAAgB,CAAC,EAAE,8BAA8B,CAAC;CACnD;AAED,MAAM,WAAW,8BAA8B;IAC7C,iEAAiE;IACjE,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,oDAAoD;IACpD,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,YAAY,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,CAAC;AAEvD,MAAM,WAAW,kBAAkB;IACjC,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,EAAE,YAAY,CAAC;IACrB,OAAO,EAAE,OAAO,CAAC;IACjB,cAAc,EAAE,OAAO,CAAC;IACxB,QAAQ,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,SAAS,EAAE,OAAO,CAAC;QAAC,WAAW,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,OAAO,CAAC;QAAC,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,UAAU,EAAE,MAAM,CAAC;QAAC,aAAa,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,CAAC;IACjM,KAAK,EAAE,iBAAiB,CAAC;IACzB,MAAM,EAAE;QAAE,OAAO,EAAE,OAAO,CAAC;QAAC,MAAM,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC;IAC9E,WAAW,EAAE,wBAAwB,CAAC;IACtC,QAAQ,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,eAAe,EAAE,MAAM,CAAC;QAAC,sBAAsB,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC,CAAA;KAAE,CAAC;IACpI,SAAS,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,MAAM,EAAE,YAAY,CAAC;QAAC,SAAS,EAAE,OAAO,CAAA;KAAE,CAAC;IAC9F,OAAO,EAAE,qBAAqB,CAAC;IAC/B,gFAAgF;IAChF,OAAO,EAAE,sBAAsB,GAAG,IAAI,CAAC;IACvC,iFAAiF;IACjF,KAAK,EAAE;QAAE,SAAS,EAAE,OAAO,CAAC;QAAC,aAAa,EAAE,MAAM,CAAA;KAAE,CAAC;CACtD;AAED,wFAAwF;AACxF,MAAM,MAAM,oBAAoB,GAAG,CAAC,OAAO,cAAc,CAAC,CAAC,MAAM,OAAO,cAAc,CAAC,CAAC;AAExF,MAAM,WAAW,kBAAkB;IACjC,MAAM,EAAE,oBAAoB,CAAC;IAC7B,OAAO,EAAE,MAAM,CAAC;IAChB,EAAE,EAAE,MAAM,CAAC;CACZ;AAED,4EAA4E;AAC5E,MAAM,WAAW,wBAAwB;IACvC,2EAA2E;IAC3E,QAAQ,EAAE,MAAM,CAAC;IACjB,aAAa,EAAE,MAAM,GAAG,IAAI,CAAC;IAC7B,gBAAgB,EAAE,MAAM,GAAG,IAAI,CAAC;CACjC;AAED;;;2BAG2B;AAC3B,MAAM,WAAW,oBAAoB;IACnC,qFAAqF;IACrF,OAAO,EAAE,OAAO,CAAC;IACjB;;0CAEsC;IACtC,KAAK,EAAE,CAAC,OAAO,YAAY,CAAC,CAAC,MAAM,OAAO,YAAY,CAAC,CAAC;IACxD,MAAM,EAAE,YAAY,CAAC;IACrB,UAAU,EAAE,MAAM,CAAC;IACnB,OAAO,EAAE,OAAO,CAAC;IACjB,SAAS,EAAE,OAAO,CAAC;IACnB,SAAS,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,KAAK,EAAE,OAAO,CAAC;QAAC,MAAM,EAAE,YAAY,CAAA;KAAE,CAAC;IAC1F,QAAQ,EAAE,UAAU,CAAC,eAAe,CAAC,kBAAkB,CAAC,CAAC,CAAC;IAC1D,yEAAyE;IACzE,WAAW,EAAE,kBAAkB,GAAG,IAAI,CAAC;IACvC,WAAW,EAAE,wBAAwB,CAAC;IACtC,6EAA6E;IAC7E,OAAO,EAAE,sBAAsB,GAAG,IAAI,CAAC;IACvC,iFAAiF;IACjF,KAAK,EAAE;QAAE,SAAS,EAAE,OAAO,CAAC;QAAC,aAAa,EAAE,MAAM,CAAA;KAAE,CAAC;CACtD;AAED,MAAM,WAAW,sBAAsB,CAAC,OAAO,EAAE,KAAK,CACpD,SAAQ,IAAI,CAAC,oBAAoB,EAAE,UAAU,CAAC;IAC9C,SAAS,EAAE,gBAAgB,CAAC,OAAO,EAAE,KAAK,CAAC,CAAC;IAC5C,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB,KAAK,CAAC,EAAE,mBAAmB,CAAC;IAC5B,8EAA8E;IAC9E,MAAM,CAAC,EAAE,oBAAoB,CAAC,KAAK,CAAC,CAAC;IACrC,mFAAmF;IACnF,KAAK,CAAC,EAAE,mBAAmB,CAAC;IAC5B,2CAA2C;IAC3C,QAAQ,CAAC,EAAE;QAAE,UAAU,CAAC,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CAC1D;AAED;;;;;;;GAOG;AACH,qBAAa,eAAe,CAAC,OAAO,GAAG,OAAO,EAAE,KAAK,GAAG,OAAO;IAC7D,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAmC;IAC7D,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAuB;IAE/C,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAwD;IAGtF,OAAO,CAAC,QAAQ,CAAC,yBAAyB,CAAqB;IAC/D,OAAO,CAAC,QAAQ,CAAC,cAAc,CAAmC;IAClE,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAkC;IAChE,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAuB;IACrD,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAsB;IACpD,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAU;IAC3C,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAuB;IAC7C,OAAO,CAAC,QAAQ,CAAC,YAAY,CAAe;IAC5C,OAAO,CAAC,QAAQ,CAAC,GAAG,CAAe;IACnC,OAAO,CAAC,YAAY,CAAsB;IAC1C,OAAO,CAAC,MAAM,CAA4C;IAC1D,OAAO,CAAC,OAAO,CAAS;IACxB,OAAO,CAAC,QAAQ,CAAS;IACzB,OAAO,CAAC,cAAc,CAAS;IAK/B,OAAO,CAAC,qBAAqB,CAAS;IAGtC,OAAO,CAAC,SAAS,CAAiB;IAClC,OAAO,CAAC,WAAW,CAAuB;IAG1C,OAAO,CAAC,WAAW,CAAmC;IACtD,OAAO,CAAC,uBAAuB,CAAK;IACpC,OAAO,CAAC,wBAAwB,CAAuB;IACvD,OAAO,CAAC,2BAA2B,CAAuB;IAG1D,OAAO,CAAC,YAAY,CAA8B;IAGlD,OAAO,CAAC,WAAW,CAA8B;IAIjD,OAAO,CAAC,WAAW,CAA8B;IAIjD,OAAO,CAAC,gBAAgB,CAA8B;IACtD,OAAO,CAAC,qBAAqB,CAAK;IAKlC,OAAO,CAAC,gBAAgB,CAAK;IAC7B,OAAO,CAAC,wBAAwB,CAAK;IAGrC,OAAO,CAAC,cAAc,CAAK;IAG3B,OAAO,CAAC,eAAe,CAAK;IAC5B,OAAO,CAAC,iBAAiB,CAAS;IAKlC,OAAO,CAAC,YAAY,CAA8B;IAClD,OAAO,CAAC,mBAAmB,CAA6B;IACxD,OAAO,CAAC,aAAa,CAA8C;IACnE,OAAO,CAAC,kBAAkB,CAAK;IAK/B,OAAO,CAAC,yBAAyB,CAAK;IAKtC,OAAO,CAAC,qBAAqB,CAAS;IAKtC,OAAO,CAAC,eAAe,CAAK;IAC5B;;4EAEwE;IACxE,OAAO,CAAC,kBAAkB,CAAK;IAC/B;gEAC4D;IAC5D,OAAO,CAAC,aAAa,CAAuB;IAG5C,OAAO,CAAC,SAAS,CAAS;IAK1B,OAAO,CAAC,WAAW,CAA8B;IAGjD,OAAO,CAAC,cAAc,CAAK;IAE3B,OAAO,CAAC,QAAQ,CAAC,kBAAkB,CAAS;IAC5C,OAAO,CAAC,QAAQ,CAAC,mBAAmB,CAAS;gBAEjC,OAAO,EAAE,sBAAsB,CAAC,OAAO,EAAE,KAAK,CAAC;IAyH3D;;;;;;;;;;OAUG;IACH,KAAK,CAAC,MAAM,EAAE,OAAO,GAAG,OAAO,CAAC,IAAI,CAAC;IAoIrC,8EAA8E;IAC9E,OAAO,CAAC,mBAAmB;IA+B3B,8EAA8E;IAC9E,OAAO,CAAC,mBAAmB;IA2D3B,yEAAyE;IACzE,OAAO,CAAC,mBAAmB;IAQ3B;;uDAEmD;IACnD,OAAO,CAAC,uBAAuB;IAU/B;;;;;;;;qCAQiC;IACjC,OAAO,CAAC,mBAAmB;IAe3B;;iFAE6E;IAC7E,OAAO,CAAC,mBAAmB;IAyB3B,+EAA+E;IAC/E,OAAO,CAAC,iBAAiB;IAczB;;;;OAIG;IACH,OAAO,CAAC,aAAa;IA4IrB;;;;;;;;;OASG;IACH,KAAK,IAAI,OAAO,CAAC,IAAI,CAAC;IA8DtB;;;;;;;;OAQG;IACH,SAAS,CACP,KAAK,EAAE,MAAM,EACb,OAAO,EAAE,qBAAqB,CAAC,KAAK,CAAC,EACrC,OAAO,CAAC,EAAE;QAAE,MAAM,CAAC,EAAE,OAAO,GAAG,MAAM,CAAA;KAAE,GACtC,MAAM,IAAI;IAqCb;;;mFAG+E;IAC/E,WAAW,CAAC,KAAK,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,qBAAqB,CAAC,KAAK,CAAC,GAAG,IAAI;IAWxE,+EAA+E;IACzE,WAAW,IAAI,OAAO,CAAC,IAAI,CAAC;IAIlC;;;eAGW;IACL,gBAAgB,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAIpD,oEAAoE;IAC9D,iBAAiB,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAIzD,+EAA+E;IAC/E,aAAa,IAAI,iBAAiB;IAIlC,wDAAwD;IACxD,UAAU,IAAI,IAAI;IAIlB;sEACkE;IAClE,OAAO,CAAC,KAAK,EAAE,MAAM,EAAE,IAAI,EAAE,OAAO,EAAE,OAAO,CAAC,EAAE,qBAAqB,GAAG,IAAI;IAW5E;;;;;;;;;OASG;IACH,YAAY,CACV,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,aAAa,CAAC;QAAE,IAAI,EAAE,OAAO,CAAC;QAAC,OAAO,CAAC,EAAE,qBAAqB,CAAA;KAAE,CAAC,GACvE,IAAI;IAqBP,mHAAmH;IACnH,QAAQ,CAAC,OAAO,EAAE,oBAAoB,GAAG,MAAM,IAAI;IAUnD,+CAA+C;IAC/C,OAAO,CAAC,OAAO,EAAE,mBAAmB,GAAG,MAAM,IAAI;IAKjD,2CAA2C;IAC3C,SAAS,IAAI,YAAY;IAIzB;;;;;;;;kBAQc;IACd,gBAAgB,IAAI;QAClB,OAAO,EAAE,MAAM,CAAC;QAChB,SAAS,EAAE,OAAO,CAAC;QACnB,WAAW,EAAE,MAAM,CAAC;QACpB,QAAQ,EAAE,OAAO,CAAC;QAClB,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;QAC5B,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QACvB,UAAU,EAAE,MAAM,CAAC;QACnB,aAAa,EAAE,MAAM,GAAG,IAAI,CAAC;KAC9B;IAcD,mEAAmE;IACnE,mBAAmB,IAAI,wBAAwB;IAQ/C;;gFAE4E;IAC5E,gBAAgB,IAAI,oBAAoB;IA+CxC;;mDAE+C;IAC/C,kBAAkB;IAIlB,uGAAuG;IACvG,cAAc,IAAI,kBAAkB;IA2BpC;;iFAE6E;IAC7E,UAAU,IAAI,sBAAsB,GAAG,IAAI;IAI3C;;;;;OAKG;IACH,IAAI,IAAI,OAAO,CAAC,IAAI,CAAC;
|
|
1
|
+
{"version":3,"file":"data-bus.d.ts","sourceRoot":"","sources":["../../src/core/data-bus.ts"],"names":[],"mappings":"AAQA,OAAO,KAAK,EAAE,oBAAoB,EAAE,qBAAqB,EAAE,MAAM,WAAW,CAAC;AAE7E,OAAO,KAAK,EACV,mBAAmB,EAEnB,qBAAqB,EACrB,qBAAqB,EACrB,oBAAoB,EACpB,gBAAgB,EAChB,YAAY,EACb,MAAM,SAAS,CAAC;AAEjB,OAAO,KAAK,EAAE,sBAAsB,EAAE,mBAAmB,EAAE,MAAM,SAAS,CAAC;AAC3E,OAAO,KAAK,EAAE,wBAAwB,EAAE,MAAM,sBAAsB,CAAC;AAGrE,OAAO,KAAK,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,iBAAiB,CAAC;AAE9E,OAAO,EAGL,cAAc,EACd,YAAY,EAEZ,cAAc,EAUf,MAAM,oBAAoB,CAAC;AAQ5B;;wBAEwB;AACxB;;;;mBAImB;AACnB,MAAM,WAAW,oBAAoB,CAAC,KAAK,GAAG,OAAO;IACnD;;;sBAGkB;IAClB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,oEAAoE;IACpE,WAAW,CAAC,EAAE,wBAAwB,CAAC,KAAK,CAAC,CAAC;IAC9C,oEAAoE;IACpE,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;qEAIiE;IACjE,aAAa,CAAC,EAAE,CAAC,OAAO,cAAc,CAAC,CAAC,MAAM,OAAO,cAAc,CAAC,CAAC;IACrE,sEAAsE;IACtE,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,wEAAwE;IACxE,gBAAgB,CAAC,EAAE,8BAA8B,CAAC;CACnD;AAED,MAAM,WAAW,8BAA8B;IAC7C,iEAAiE;IACjE,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,oDAAoD;IACpD,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,YAAY,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,CAAC;AAEvD,MAAM,WAAW,kBAAkB;IACjC,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,EAAE,YAAY,CAAC;IACrB,OAAO,EAAE,OAAO,CAAC;IACjB,cAAc,EAAE,OAAO,CAAC;IACxB,QAAQ,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,SAAS,EAAE,OAAO,CAAC;QAAC,WAAW,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,OAAO,CAAC;QAAC,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,UAAU,EAAE,MAAM,CAAC;QAAC,aAAa,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,CAAC;IACjM,KAAK,EAAE,iBAAiB,CAAC;IACzB,MAAM,EAAE;QAAE,OAAO,EAAE,OAAO,CAAC;QAAC,MAAM,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC;IAC9E,WAAW,EAAE,wBAAwB,CAAC;IACtC,QAAQ,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,eAAe,EAAE,MAAM,CAAC;QAAC,sBAAsB,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC,CAAA;KAAE,CAAC;IACpI,SAAS,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,MAAM,EAAE,YAAY,CAAC;QAAC,SAAS,EAAE,OAAO,CAAA;KAAE,CAAC;IAC9F,OAAO,EAAE,qBAAqB,CAAC;IAC/B,gFAAgF;IAChF,OAAO,EAAE,sBAAsB,GAAG,IAAI,CAAC;IACvC,iFAAiF;IACjF,KAAK,EAAE;QAAE,SAAS,EAAE,OAAO,CAAC;QAAC,aAAa,EAAE,MAAM,CAAA;KAAE,CAAC;CACtD;AAED,wFAAwF;AACxF,MAAM,MAAM,oBAAoB,GAAG,CAAC,OAAO,cAAc,CAAC,CAAC,MAAM,OAAO,cAAc,CAAC,CAAC;AAExF,MAAM,WAAW,kBAAkB;IACjC,MAAM,EAAE,oBAAoB,CAAC;IAC7B,OAAO,EAAE,MAAM,CAAC;IAChB,EAAE,EAAE,MAAM,CAAC;CACZ;AAED,4EAA4E;AAC5E,MAAM,WAAW,wBAAwB;IACvC,2EAA2E;IAC3E,QAAQ,EAAE,MAAM,CAAC;IACjB,aAAa,EAAE,MAAM,GAAG,IAAI,CAAC;IAC7B,gBAAgB,EAAE,MAAM,GAAG,IAAI,CAAC;CACjC;AAED;;;2BAG2B;AAC3B,MAAM,WAAW,oBAAoB;IACnC,qFAAqF;IACrF,OAAO,EAAE,OAAO,CAAC;IACjB;;0CAEsC;IACtC,KAAK,EAAE,CAAC,OAAO,YAAY,CAAC,CAAC,MAAM,OAAO,YAAY,CAAC,CAAC;IACxD,MAAM,EAAE,YAAY,CAAC;IACrB,UAAU,EAAE,MAAM,CAAC;IACnB,OAAO,EAAE,OAAO,CAAC;IACjB,SAAS,EAAE,OAAO,CAAC;IACnB,SAAS,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,KAAK,EAAE,OAAO,CAAC;QAAC,MAAM,EAAE,YAAY,CAAA;KAAE,CAAC;IAC1F,QAAQ,EAAE,UAAU,CAAC,eAAe,CAAC,kBAAkB,CAAC,CAAC,CAAC;IAC1D,yEAAyE;IACzE,WAAW,EAAE,kBAAkB,GAAG,IAAI,CAAC;IACvC,WAAW,EAAE,wBAAwB,CAAC;IACtC,6EAA6E;IAC7E,OAAO,EAAE,sBAAsB,GAAG,IAAI,CAAC;IACvC,iFAAiF;IACjF,KAAK,EAAE;QAAE,SAAS,EAAE,OAAO,CAAC;QAAC,aAAa,EAAE,MAAM,CAAA;KAAE,CAAC;CACtD;AAED,MAAM,WAAW,sBAAsB,CAAC,OAAO,EAAE,KAAK,CACpD,SAAQ,IAAI,CAAC,oBAAoB,EAAE,UAAU,CAAC;IAC9C,SAAS,EAAE,gBAAgB,CAAC,OAAO,EAAE,KAAK,CAAC,CAAC;IAC5C,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB,KAAK,CAAC,EAAE,mBAAmB,CAAC;IAC5B,8EAA8E;IAC9E,MAAM,CAAC,EAAE,oBAAoB,CAAC,KAAK,CAAC,CAAC;IACrC,mFAAmF;IACnF,KAAK,CAAC,EAAE,mBAAmB,CAAC;IAC5B,2CAA2C;IAC3C,QAAQ,CAAC,EAAE;QAAE,UAAU,CAAC,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CAC1D;AAED;;;;;;;GAOG;AACH,qBAAa,eAAe,CAAC,OAAO,GAAG,OAAO,EAAE,KAAK,GAAG,OAAO;IAC7D,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAmC;IAC7D,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAuB;IAE/C,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAwD;IAGtF,OAAO,CAAC,QAAQ,CAAC,yBAAyB,CAAqB;IAC/D,OAAO,CAAC,QAAQ,CAAC,cAAc,CAAmC;IAClE,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAkC;IAChE,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAuB;IACrD,OAAO,CAAC,QAAQ,CAAC,aAAa,CAAsB;IACpD,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAU;IAC3C,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAuB;IAC7C,OAAO,CAAC,QAAQ,CAAC,YAAY,CAAe;IAC5C,OAAO,CAAC,QAAQ,CAAC,GAAG,CAAe;IACnC,OAAO,CAAC,YAAY,CAAsB;IAC1C,OAAO,CAAC,MAAM,CAA4C;IAC1D,OAAO,CAAC,OAAO,CAAS;IACxB,OAAO,CAAC,QAAQ,CAAS;IACzB,OAAO,CAAC,cAAc,CAAS;IAK/B,OAAO,CAAC,qBAAqB,CAAS;IAGtC,OAAO,CAAC,SAAS,CAAiB;IAClC,OAAO,CAAC,WAAW,CAAuB;IAG1C,OAAO,CAAC,WAAW,CAAmC;IACtD,OAAO,CAAC,uBAAuB,CAAK;IACpC,OAAO,CAAC,wBAAwB,CAAuB;IACvD,OAAO,CAAC,2BAA2B,CAAuB;IAG1D,OAAO,CAAC,YAAY,CAA8B;IAGlD,OAAO,CAAC,WAAW,CAA8B;IAIjD,OAAO,CAAC,WAAW,CAA8B;IAIjD,OAAO,CAAC,gBAAgB,CAA8B;IACtD,OAAO,CAAC,qBAAqB,CAAK;IAKlC,OAAO,CAAC,gBAAgB,CAAK;IAC7B,OAAO,CAAC,wBAAwB,CAAK;IAGrC,OAAO,CAAC,cAAc,CAAK;IAG3B,OAAO,CAAC,eAAe,CAAK;IAC5B,OAAO,CAAC,iBAAiB,CAAS;IAKlC,OAAO,CAAC,YAAY,CAA8B;IAClD,OAAO,CAAC,mBAAmB,CAA6B;IACxD,OAAO,CAAC,aAAa,CAA8C;IACnE,OAAO,CAAC,kBAAkB,CAAK;IAK/B,OAAO,CAAC,yBAAyB,CAAK;IAKtC,OAAO,CAAC,qBAAqB,CAAS;IAKtC,OAAO,CAAC,eAAe,CAAK;IAC5B;;4EAEwE;IACxE,OAAO,CAAC,kBAAkB,CAAK;IAC/B;gEAC4D;IAC5D,OAAO,CAAC,aAAa,CAAuB;IAG5C,OAAO,CAAC,SAAS,CAAS;IAK1B,OAAO,CAAC,WAAW,CAA8B;IAGjD,OAAO,CAAC,cAAc,CAAK;IAE3B,OAAO,CAAC,QAAQ,CAAC,kBAAkB,CAAS;IAC5C,OAAO,CAAC,QAAQ,CAAC,mBAAmB,CAAS;gBAEjC,OAAO,EAAE,sBAAsB,CAAC,OAAO,EAAE,KAAK,CAAC;IAyH3D;;;;;;;;;;OAUG;IACH,KAAK,CAAC,MAAM,EAAE,OAAO,GAAG,OAAO,CAAC,IAAI,CAAC;IAoIrC,8EAA8E;IAC9E,OAAO,CAAC,mBAAmB;IA+B3B,8EAA8E;IAC9E,OAAO,CAAC,mBAAmB;IA2D3B,yEAAyE;IACzE,OAAO,CAAC,mBAAmB;IAQ3B;;uDAEmD;IACnD,OAAO,CAAC,uBAAuB;IAU/B;;;;;;;;qCAQiC;IACjC,OAAO,CAAC,mBAAmB;IAe3B;;iFAE6E;IAC7E,OAAO,CAAC,mBAAmB;IAyB3B,+EAA+E;IAC/E,OAAO,CAAC,iBAAiB;IAczB;;;;OAIG;IACH,OAAO,CAAC,aAAa;IA4IrB;;;;;;;;;OASG;IACH,KAAK,IAAI,OAAO,CAAC,IAAI,CAAC;IA8DtB;;;;;;;;OAQG;IACH,SAAS,CACP,KAAK,EAAE,MAAM,EACb,OAAO,EAAE,qBAAqB,CAAC,KAAK,CAAC,EACrC,OAAO,CAAC,EAAE;QAAE,MAAM,CAAC,EAAE,OAAO,GAAG,MAAM,CAAA;KAAE,GACtC,MAAM,IAAI;IAqCb;;;mFAG+E;IAC/E,WAAW,CAAC,KAAK,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,qBAAqB,CAAC,KAAK,CAAC,GAAG,IAAI;IAWxE,+EAA+E;IACzE,WAAW,IAAI,OAAO,CAAC,IAAI,CAAC;IAIlC;;;eAGW;IACL,gBAAgB,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAIpD,oEAAoE;IAC9D,iBAAiB,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAIzD,+EAA+E;IAC/E,aAAa,IAAI,iBAAiB;IAIlC,wDAAwD;IACxD,UAAU,IAAI,IAAI;IAIlB;sEACkE;IAClE,OAAO,CAAC,KAAK,EAAE,MAAM,EAAE,IAAI,EAAE,OAAO,EAAE,OAAO,CAAC,EAAE,qBAAqB,GAAG,IAAI;IAW5E;;;;;;;;;OASG;IACH,YAAY,CACV,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,aAAa,CAAC;QAAE,IAAI,EAAE,OAAO,CAAC;QAAC,OAAO,CAAC,EAAE,qBAAqB,CAAA;KAAE,CAAC,GACvE,IAAI;IAqBP,mHAAmH;IACnH,QAAQ,CAAC,OAAO,EAAE,oBAAoB,GAAG,MAAM,IAAI;IAUnD,+CAA+C;IAC/C,OAAO,CAAC,OAAO,EAAE,mBAAmB,GAAG,MAAM,IAAI;IAKjD,2CAA2C;IAC3C,SAAS,IAAI,YAAY;IAIzB;;;;;;;;kBAQc;IACd,gBAAgB,IAAI;QAClB,OAAO,EAAE,MAAM,CAAC;QAChB,SAAS,EAAE,OAAO,CAAC;QACnB,WAAW,EAAE,MAAM,CAAC;QACpB,QAAQ,EAAE,OAAO,CAAC;QAClB,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;QAC5B,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;QACvB,UAAU,EAAE,MAAM,CAAC;QACnB,aAAa,EAAE,MAAM,GAAG,IAAI,CAAC;KAC9B;IAcD,mEAAmE;IACnE,mBAAmB,IAAI,wBAAwB;IAQ/C;;gFAE4E;IAC5E,gBAAgB,IAAI,oBAAoB;IA+CxC;;mDAE+C;IAC/C,kBAAkB;IAIlB,uGAAuG;IACvG,cAAc,IAAI,kBAAkB;IA2BpC;;iFAE6E;IAC7E,UAAU,IAAI,sBAAsB,GAAG,IAAI;IAI3C;;;;;OAKG;IACH,IAAI,IAAI,OAAO,CAAC,IAAI,CAAC;IA4HrB;;;;;;OAMG;IACH,OAAO,CAAC,SAAS;YAaH,WAAW;IAqDzB;;;;OAIG;IACH,OAAO,CAAC,sBAAsB;IA4B9B,kFAAkF;IAClF,OAAO,CAAC,eAAe;IAIvB,6CAA6C;IAC7C,OAAO,CAAC,cAAc;IAItB;;;;sFAIkF;IAClF,OAAO,CAAC,QAAQ;IA2BhB;;;OAGG;IACH,OAAO,CAAC,YAAY;IA+GpB,OAAO,CAAC,WAAW;IA4BnB,OAAO,CAAC,WAAW;IAInB,OAAO,CAAC,WAAW;IAKnB;;4DAEwD;IACxD,OAAO,CAAC,sBAAsB;IAM9B,OAAO,CAAC,iBAAiB;IASzB;;;;;;;;;;gBAUY;IACZ,OAAO,CAAC,qBAAqB;IAW7B,8DAA8D;IAC9D,OAAO,CAAC,kBAAkB;IAe1B,OAAO,CAAC,oBAAoB;IAe5B;;;;+CAI2C;IAC3C,OAAO,CAAC,cAAc;IAoBtB;;iFAE6E;IAC7E,OAAO,CAAC,wBAAwB;IAUhC;;;OAGG;IACH,OAAO,CAAC,gBAAgB;IAqCxB;qEACiE;IACjE,OAAO,CAAC,iBAAiB;IAMzB;;;;;OAKG;IACH,OAAO,CAAC,eAAe;IAIvB;;;;;OAKG;IACH,OAAO,CAAC,eAAe;IAuJvB;;;;;;;;;;;OAWG;IACH,OAAO,CAAC,YAAY;IAwJpB;;;;;OAKG;IACH,OAAO,CAAC,uBAAuB;IAS/B;;;;;;;;;OASG;IACH,OAAO,CAAC,aAAa;CAUtB"}
|
package/dist/core/hash.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"hash.d.ts","sourceRoot":"","sources":["../../src/core/hash.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,
|
|
1
|
+
{"version":3,"file":"hash.d.ts","sourceRoot":"","sources":["../../src/core/hash.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAkCrD"}
|
package/dist/core/trace.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"trace.d.ts","sourceRoot":"","sources":["../../src/core/trace.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,SAAS,CAAC;AAC5C,OAAO,KAAK,EACV,qBAAqB,EACrB,gBAAgB,EAChB,qBAAqB,EACrB,mBAAmB,EACnB,kBAAkB,EAClB,sBAAsB,EACvB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EAEL,gBAAgB,EAChB,UAAU,EACX,MAAM,oBAAoB,CAAC;AAE5B,uEAAuE;AACvE;;;;;yDAKyD;AACzD,MAAM,MAAM,gBAAgB,GAAG,CAAC,OAAO,UAAU,CAAC,CAAC,MAAM,OAAO,UAAU,CAAC,CAAC;AAE5E,oEAAoE;AACpE,MAAM,WAAW,0BAA0B;IACzC,IAAI,EAAE,OAAO,gBAAgB,CAAC,SAAS,CAAC;IACxC,MAAM,EAAE,CAAC,OAAO,sBAAsB,CAAC,CAAC,MAAM,OAAO,sBAAsB,CAAC,CAAC;IAC7E,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,4DAA4D;AAC5D,MAAM,WAAW,uBAAuB;IACtC,IAAI,EAAE,OAAO,gBAAgB,CAAC,MAAM,CAAC;IACrC,MAAM,EAAE,YAAY,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,6DAA6D;AAC7D,MAAM,WAAW,6BAA6B;IAC5C,IAAI,EAAE,OAAO,gBAAgB,CAAC,YAAY,CAAC;IAC3C,MAAM,EAAE,CAAC,OAAO,mBAAmB,CAAC,CAAC,MAAM,OAAO,mBAAmB,CAAC,CAAC;IACvE,KAAK,EAAE,MAAM,CAAC;IACd,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED;;;;;uEAKuE;AACvE,MAAM,WAAW,6BAA6B;IAC5C,IAAI,EAAE,OAAO,gBAAgB,CAAC,YAAY,CAAC;IAC3C,WAAW,EAAE,OAAO,CAAC;IACrB,aAAa,EAAE,MAAM,CAAC;IACtB,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,0DAA0D;AAC1D,MAAM,WAAW,sBAAsB;IACrC,IAAI,EAAE,OAAO,gBAAgB,CAAC,KAAK,CAAC;IACpC,MAAM,EAAE,CAAC,OAAO,kBAAkB,CAAC,CAAC,MAAM,OAAO,kBAAkB,CAAC,CAAC;IACrE,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,qFAAqF;AACrF,MAAM,WAAW,4BAA4B;IAC3C,IAAI,EAAE,OAAO,gBAAgB,CAAC,WAAW,CAAC;IAC1C,SAAS,EAAE,CAAC,OAAO,qBAAqB,CAAC,CAAC,MAAM,OAAO,qBAAqB,CAAC,CAAC;IAC9E,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,oBAAoB,CAAC,EAAE,CAAC,OAAO,qBAAqB,CAAC,CAAC,MAAM,OAAO,qBAAqB,CAAC,CAAC;IAC1F,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,gDAAgD;IAChD,OAAO,CAAC,EAAE,CAAC,OAAO,gBAAgB,CAAC,CAAC,MAAM,OAAO,gBAAgB,CAAC,CAAC;IACnE,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED;;;;GAIG;AACH,MAAM,WAAW,wBAAwB;IACvC,IAAI,EAAE,OAAO,gBAAgB,CAAC,eAAe,CAAC;IAC9C,UAAU,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;IACjB,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,EAAE,MAAM,CAAC;IACf,eAAe,EAAE,MAAM,CAAC;IACxB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED;;;;;GAKG;AACH,MAAM,WAAW,sBAAsB;IACrC,8DAA8D;IAC9D,UAAU,EAAE,MAAM,CAAC;IACnB,uCAAuC;IACvC,QAAQ,EAAE,MAAM,CAAC;IACjB,iDAAiD;IACjD,UAAU,EAAE,MAAM,CAAC;IACnB,6CAA6C;IAC7C,MAAM,EAAE,MAAM,CAAC;IACf,+CAA+C;IAC/C,eAAe,EAAE,MAAM,CAAC;IACxB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,MAAM,iBAAiB,GACzB,0BAA0B,GAC1B,uBAAuB,GACvB,6BAA6B,GAC7B,6BAA6B,GAC7B,sBAAsB,GACtB,4BAA4B,GAC5B,wBAAwB,CAAC;AAE7B,yGAAyG;AACzG,KAAK,sBAAsB,GAAG,iBAAiB,SAAS,MAAM,MAAM,GAChE,MAAM,SAAS,iBAAiB,GAC9B,IAAI,CAAC,MAAM,EAAE,WAAW,CAAC,GACzB,KAAK,GACP,KAAK,CAAC;AAEV;wEACwE;AACxE,MAAM,WAAW,mBAAmB;IAClC;;yEAEqE;IACrE,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,qDAAqD;IACrD,IAAI,CAAC,EAAE,gBAAgB,CAAC;IACxB,oEAAoE;IACpE,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,4EAA4E;IAC5E,GAAG,CAAC,EAAE,MAAM,MAAM,CAAC;IACnB,qDAAqD;IACrD,IAAI,EAAE,CAAC,KAAK,EAAE,iBAAiB,KAAK,IAAI,CAAC;IACzC,2EAA2E;IAC3E,SAAS,CAAC,EAAE,OAAO,CAAC;CACrB;AAWD;;;;;;GAMG;AACH,qBAAa,oBAAoB;IAC/B,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAU;IAClC,OAAO,CAAC,QAAQ,CAAC,IAAI,CAAmB;IACxC,OAAO,CAAC,QAAQ,CAAC,iBAAiB,CAAS;IAC3C,OAAO,CAAC,QAAQ,CAAC,IAAI,CAAqC;IAC1D,OAAO,CAAC,QAAQ,CAAC,GAAG,CAAe;IACnC,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAU;IACpC,OAAO,CAAC,aAAa,CAA2B;IAChD,OAAO,CAAC,kBAAkB,CAAS;IACnC,OAAO,CAAC,cAAc,CAA+C;IACrE,OAAO,CAAC,iBAAiB,CAAK;IAG9B,OAAO,CAAC,OAAO,CAAS;IACxB,OAAO,CAAC,QAAQ,CAAK;IACrB,OAAO,CAAC,UAAU,CAAK;IACvB,OAAO,CAAC,cAAc,CAAK;IAC3B,OAAO,CAAC,QAAQ,CAAC,MAAM,CAAqB;IAE5C,OAAO,CAAC,QAAQ,CAAC,UAAU,CAA+B;IAE1D,OAAO,CAAC,QAAQ,CAAC,cAAc,CAAmD;IAClF,OAAO,CAAC,YAAY,CAAK;IACzB,OAAO,CAAC,aAAa,CAAK;IAC1B,OAAO,CAAC,eAAe,CAAK;gBAEhB,OAAO,CAAC,EAAE,mBAAmB,EAAE,GAAG,GAAE,MAAM,MAAiC;
|
|
1
|
+
{"version":3,"file":"trace.d.ts","sourceRoot":"","sources":["../../src/core/trace.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,SAAS,CAAC;AAC5C,OAAO,KAAK,EACV,qBAAqB,EACrB,gBAAgB,EAChB,qBAAqB,EACrB,mBAAmB,EACnB,kBAAkB,EAClB,sBAAsB,EACvB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EAEL,gBAAgB,EAChB,UAAU,EACX,MAAM,oBAAoB,CAAC;AAE5B,uEAAuE;AACvE;;;;;yDAKyD;AACzD,MAAM,MAAM,gBAAgB,GAAG,CAAC,OAAO,UAAU,CAAC,CAAC,MAAM,OAAO,UAAU,CAAC,CAAC;AAE5E,oEAAoE;AACpE,MAAM,WAAW,0BAA0B;IACzC,IAAI,EAAE,OAAO,gBAAgB,CAAC,SAAS,CAAC;IACxC,MAAM,EAAE,CAAC,OAAO,sBAAsB,CAAC,CAAC,MAAM,OAAO,sBAAsB,CAAC,CAAC;IAC7E,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,4DAA4D;AAC5D,MAAM,WAAW,uBAAuB;IACtC,IAAI,EAAE,OAAO,gBAAgB,CAAC,MAAM,CAAC;IACrC,MAAM,EAAE,YAAY,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,6DAA6D;AAC7D,MAAM,WAAW,6BAA6B;IAC5C,IAAI,EAAE,OAAO,gBAAgB,CAAC,YAAY,CAAC;IAC3C,MAAM,EAAE,CAAC,OAAO,mBAAmB,CAAC,CAAC,MAAM,OAAO,mBAAmB,CAAC,CAAC;IACvE,KAAK,EAAE,MAAM,CAAC;IACd,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED;;;;;uEAKuE;AACvE,MAAM,WAAW,6BAA6B;IAC5C,IAAI,EAAE,OAAO,gBAAgB,CAAC,YAAY,CAAC;IAC3C,WAAW,EAAE,OAAO,CAAC;IACrB,aAAa,EAAE,MAAM,CAAC;IACtB,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,0DAA0D;AAC1D,MAAM,WAAW,sBAAsB;IACrC,IAAI,EAAE,OAAO,gBAAgB,CAAC,KAAK,CAAC;IACpC,MAAM,EAAE,CAAC,OAAO,kBAAkB,CAAC,CAAC,MAAM,OAAO,kBAAkB,CAAC,CAAC;IACrE,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,qFAAqF;AACrF,MAAM,WAAW,4BAA4B;IAC3C,IAAI,EAAE,OAAO,gBAAgB,CAAC,WAAW,CAAC;IAC1C,SAAS,EAAE,CAAC,OAAO,qBAAqB,CAAC,CAAC,MAAM,OAAO,qBAAqB,CAAC,CAAC;IAC9E,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,oBAAoB,CAAC,EAAE,CAAC,OAAO,qBAAqB,CAAC,CAAC,MAAM,OAAO,qBAAqB,CAAC,CAAC;IAC1F,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,gDAAgD;IAChD,OAAO,CAAC,EAAE,CAAC,OAAO,gBAAgB,CAAC,CAAC,MAAM,OAAO,gBAAgB,CAAC,CAAC;IACnE,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED;;;;GAIG;AACH,MAAM,WAAW,wBAAwB;IACvC,IAAI,EAAE,OAAO,gBAAgB,CAAC,eAAe,CAAC;IAC9C,UAAU,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;IACjB,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,EAAE,MAAM,CAAC;IACf,eAAe,EAAE,MAAM,CAAC;IACxB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED;;;;;GAKG;AACH,MAAM,WAAW,sBAAsB;IACrC,8DAA8D;IAC9D,UAAU,EAAE,MAAM,CAAC;IACnB,uCAAuC;IACvC,QAAQ,EAAE,MAAM,CAAC;IACjB,iDAAiD;IACjD,UAAU,EAAE,MAAM,CAAC;IACnB,6CAA6C;IAC7C,MAAM,EAAE,MAAM,CAAC;IACf,+CAA+C;IAC/C,eAAe,EAAE,MAAM,CAAC;IACxB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,SAAS,EAAE,MAAM,CAAC;CACnB;AAED,MAAM,MAAM,iBAAiB,GACzB,0BAA0B,GAC1B,uBAAuB,GACvB,6BAA6B,GAC7B,6BAA6B,GAC7B,sBAAsB,GACtB,4BAA4B,GAC5B,wBAAwB,CAAC;AAE7B,yGAAyG;AACzG,KAAK,sBAAsB,GAAG,iBAAiB,SAAS,MAAM,MAAM,GAChE,MAAM,SAAS,iBAAiB,GAC9B,IAAI,CAAC,MAAM,EAAE,WAAW,CAAC,GACzB,KAAK,GACP,KAAK,CAAC;AAEV;wEACwE;AACxE,MAAM,WAAW,mBAAmB;IAClC;;yEAEqE;IACrE,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,qDAAqD;IACrD,IAAI,CAAC,EAAE,gBAAgB,CAAC;IACxB,oEAAoE;IACpE,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,4EAA4E;IAC5E,GAAG,CAAC,EAAE,MAAM,MAAM,CAAC;IACnB,qDAAqD;IACrD,IAAI,EAAE,CAAC,KAAK,EAAE,iBAAiB,KAAK,IAAI,CAAC;IACzC,2EAA2E;IAC3E,SAAS,CAAC,EAAE,OAAO,CAAC;CACrB;AAWD;;;;;;GAMG;AACH,qBAAa,oBAAoB;IAC/B,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAU;IAClC,OAAO,CAAC,QAAQ,CAAC,IAAI,CAAmB;IACxC,OAAO,CAAC,QAAQ,CAAC,iBAAiB,CAAS;IAC3C,OAAO,CAAC,QAAQ,CAAC,IAAI,CAAqC;IAC1D,OAAO,CAAC,QAAQ,CAAC,GAAG,CAAe;IACnC,OAAO,CAAC,QAAQ,CAAC,SAAS,CAAU;IACpC,OAAO,CAAC,aAAa,CAA2B;IAChD,OAAO,CAAC,kBAAkB,CAAS;IACnC,OAAO,CAAC,cAAc,CAA+C;IACrE,OAAO,CAAC,iBAAiB,CAAK;IAG9B,OAAO,CAAC,OAAO,CAAS;IACxB,OAAO,CAAC,QAAQ,CAAK;IACrB,OAAO,CAAC,UAAU,CAAK;IACvB,OAAO,CAAC,cAAc,CAAK;IAC3B,OAAO,CAAC,QAAQ,CAAC,MAAM,CAAqB;IAE5C,OAAO,CAAC,QAAQ,CAAC,UAAU,CAA+B;IAE1D,OAAO,CAAC,QAAQ,CAAC,cAAc,CAAmD;IAClF,OAAO,CAAC,YAAY,CAAK;IACzB,OAAO,CAAC,aAAa,CAAK;IAC1B,OAAO,CAAC,eAAe,CAAK;gBAEhB,OAAO,CAAC,EAAE,mBAAmB,EAAE,GAAG,GAAE,MAAM,MAAiC;IAwBvF;;;6EAGyE;IACzE,KAAK,IAAI,IAAI;IAQb,iEAAiE;IACjE,KAAK,IAAI,IAAI;IAOb,IAAI,IAAI,IAAI;IAQZ;;oEAEgE;IAChE,YAAY,IAAI;QAAE,SAAS,EAAE,OAAO,CAAC;QAAC,aAAa,EAAE,MAAM,CAAA;KAAE;IAI7D,4EAA4E;IAC5E,KAAK,CAAC,KAAK,EAAE,sBAAsB,GAAG,IAAI;IAK1C;;;;yBAIqB;IACrB,UAAU,IAAI,sBAAsB,GAAG,IAAI;IAoB3C,gGAAgG;IAChG,cAAc,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI;IA0BnC;;;;OAIG;IACH,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI;IAQpC;;;;;;OAMG;IACH,gBAAgB,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI;IAqCrC,iEAAiE;IACjE,mBAAmB,IAAI,IAAI;IAI3B,qBAAqB,IAAI,IAAI;IAI7B;;;;;;;;;;;;;;;;;oFAiBgF;IAChF,OAAO,KAAK,aAAa,GAExB;IAED,uEAAuE;IACvE,KAAK,IAAI,IAAI;IAKb,OAAO,CAAC,QAAQ;IA0DhB,OAAO,CAAC,YAAY;IAYpB,OAAO,CAAC,IAAI;IAiBZ,OAAO,CAAC,QAAQ;CAWjB"}
|
package/dist/index.js
CHANGED
package/docs/architecture.md
CHANGED
|
@@ -227,14 +227,15 @@ The cache exists for two reasons:
|
|
|
227
227
|
|
|
228
228
|
2. **Avoid re-hashing on every reconcile.** Each reconcile cycle iterates `subscribedTopics` and calls `rememberTopic` for each topic. The cache is updated unconditionally (hash is cheap, so there is no hit/miss penalty), but the reverse mapping is essential for the storage-less path.
|
|
229
229
|
|
|
230
|
-
**Cap and eviction.** The cache is capped at `MAX_KNOWN_TOPICS = 500` entries.
|
|
230
|
+
**Cap and eviction.** The cache is capped at `MAX_KNOWN_TOPICS = 500` entries, and what that bound covers is entries this worker does **not** own. Every `CONTROL` message the handler processes calls `rememberTopic`, and when the eviction scan reaches the end of the cache without finding an unowned entry it declines to drop anything — owned keys stay because the storage-less read path recovers their plaintext only from this cache. So a peer that posts `CONTROL/SUBSCRIBE` for arbitrary topics is not stopped by this cap: each such frame is adopted, which makes its key owned and therefore unevictable. Measured on 1,200 peer SUBSCRIBE frames: `knownTopics` grew to 1,200 entries along with `assignedTopics`, and one reconcile tick took both back to `0` — because an adoption with no durable route to confirm is transient by design. For that flood the memory bound is the sweep, not the cap.
|
|
231
231
|
|
|
232
232
|
One memo of the same shape has since been **removed rather than capped**, and the reason is worth keeping: `wildcardPublishCache` mapped a concrete topic to the local wildcard pattern that matched it (or `null` for "scanned, nothing matched"), growing one entry per distinct topic this worker published and bounded by nothing. Measured: 1,200 `publish()` calls on distinct topic names left `knownTopics` at its 500 entries while that map held 1,200. It had no eviction rule because neither value shape could safely be forgotten — and that turned out to be the wrong question. The stored value decided nothing at all: both shapes were read only as "have I scanned this topic yet", and the single routing effect was that a topic's *first* publication, on a wildcard match, was dispatched locally without consulting the durable route. With one worker holding `chat.*` and a peer concretely owning `chat.room.1`, three publications from the wildcard holder delivered `1,0,0` to itself and `0,1,1` to the owner — the first was never forwarded, and delivery is at-most-once. So the fast path is gone, every non-owned publication now resolves its owner through the route, and with it went the map: the unbounded growth was a side effect of an optimization that was also the bug.
|
|
233
233
|
|
|
234
|
-
Eviction is FIFO (insertion order, Map iteration order). When the cache exceeds the cap, the
|
|
234
|
+
Eviction is FIFO (insertion order, Map iteration order). When the cache exceeds the cap, the scan removes the **first** entry it is allowed to drop and then stops — one deletion is enough to get back under the cap, and dropping more would discard resolvable topics for nothing:
|
|
235
235
|
|
|
236
|
-
- An entry is **never evicted** if the current worker still owns it (`assignedTopics.has(
|
|
237
|
-
- The
|
|
236
|
+
- An entry is **never evicted** if the current worker still owns it (the scan's `this.assignedTopics.has(candidate)` skip), because the storage-less `readRoute` path depends on it.
|
|
237
|
+
- The key being remembered is never evicted by its own call (the same skip's `candidate === topicKey` term). A fresh `Map.set` lands at the back, so the scan only reaches it when every older entry is owned — and there dropping it would discard the mapping the call exists to install. Pinned by `tests/cluster.test.ts`'s "keeps the topic it is remembering when the cache is full and every older entry is owned".
|
|
238
|
+
- When nothing is eligible the cap slips rather than evicting an owned key; owned topics outrank a bounded cache, and a slipping cap is visible in `getSnapshot().knownTopics` while a lost mapping is not.
|
|
238
239
|
- Reads do not promote recency, so this is not true LRU. Hashing is cheap enough that a missed reverse-lookup merely recomputes the key.
|
|
239
240
|
|
|
240
241
|
**`isAssigned` bypasses the cache.** `isAssigned(topic)` calls `createOpaqueKey(topic)` directly rather than `rememberTopic()`. This is deliberate: `isAssigned` is a read-only query, not a state change, so it must not populate `knownTopics` (which could evict an entry the storage-less path needs). It also prefers the synchronous `assignedTopics` Map over reading the route from storage, avoiding a race with the `BatchingStorageWriter` flush window.
|
|
@@ -257,14 +258,14 @@ Eviction is FIFO (insertion order, Map iteration order). When the cache exceeds
|
|
|
257
258
|
| `CONTROL/UNSUBSCRIBE` received | no direct deletion | `rememberTopic` still caches the topic; the entry is later removed by `reconcileAssignedTopics` once the route no longer points to this worker |
|
|
258
259
|
| `reconcileAssignedTopics` | `delete(topicKey)` if not subscribed and not owned | Route no longer points to us — clean up unless we're still a subscriber |
|
|
259
260
|
| `stop()` | `clear()` | Full teardown |
|
|
260
|
-
| FIFO eviction (next `rememberTopic` call) | `delete
|
|
261
|
+
| FIFO eviction (next `rememberTopic` call) | scan from the oldest and `delete` the first key that is neither in `assignedTopics` nor the key being remembered, then stop | Cache size exceeded `MAX_KNOWN_TOPICS`; owned keys and the new key are both skipped, so when every entry is owned the cap slips |
|
|
261
262
|
|
|
262
263
|
**Storage-less fallback dependency.** When `this.storage` is `null` (degraded mode), `readRoute()` and `readSubscriberTabIds()` cannot query persisted records. They reconstruct routes from in-memory state alone:
|
|
263
264
|
|
|
264
265
|
- `readRoute(topicKey)` → looks up `knownTopics.get(topicKey)` to recover the plaintext topic, then checks `subscribedTopics.has(topic)` or `assignedTopics.has(topicKey)` to determine if this worker is the owner.
|
|
265
266
|
- `readSubscriberTabIds(topicKey, workers)` → `knownTopics.get(topicKey)` recovers the plaintext topic, then checks `subscribedTopics.has(topic)` — if we are a subscriber, we are the only subscriber (no storage means no cross-tab coordination).
|
|
266
267
|
|
|
267
|
-
This is why `assignedTopics` guards the FIFO eviction: evicting a key we still own would silently break `readRoute()` in storage-less mode, causing `isAssigned()` to disagree with `readRoute()`.
|
|
268
|
+
This is why `assignedTopics` guards the FIFO eviction: evicting a key we still own would silently break `readRoute()` in storage-less mode, causing `isAssigned()` to disagree with `readRoute()`. The scan skips the key it was called with for the same kind of reason — deleting it would discard the very mapping this call exists to install — and it only ever gets that far when every older entry is owned, because a fresh `set` lands at the back of an insertion-ordered `Map`.
|
|
268
269
|
|
|
269
270
|
### One subscription and publication flow
|
|
270
271
|
|
|
@@ -337,8 +338,8 @@ Every keyed piece of state in the system — the full picture of what the previo
|
|
|
337
338
|
| `topicHandlers` | `CrossTabDataBus` | Plaintext `topic` | `Set<handler>` | Added/removed by app `subscribe`/`unsubscribe`; entry deleted when its last handler leaves | Reference-counts application-level handlers; belongs to the business layer |
|
|
338
339
|
| `transportSubscribedTopics` | `CrossTabDataBus` | Plaintext `topic` | marker | Cleared on disconnect; replayed from `assignedTopics` on reconnect | Tracks what the live transport connection actually holds; dies with the connection |
|
|
339
340
|
| `subscribedTopics` | `WorkerClusterRuntime` | Plaintext `topic` | marker | Grows as the first local handler subscribes; shrinks when the last one leaves | The Tab's durable subscription intent, survives transport failures |
|
|
340
|
-
| `assignedTopics` | `WorkerClusterRuntime` | `topicKey` | Plaintext `topic` | Set on receiving `CONTROL/SUBSCRIBE`; cleared on `CONTROL/UNSUBSCRIBE` or handoff | The authoritative "what I own" set; drives `isAssigned` and load |
|
|
341
|
-
| `knownTopics` | `WorkerClusterRuntime` | `topicKey` | Plaintext `topic` | FIFO
|
|
341
|
+
| `assignedTopics` | `WorkerClusterRuntime` | `topicKey` | Plaintext `topic` | Set on receiving `CONTROL/SUBSCRIBE`; cleared on `CONTROL/UNSUBSCRIBE` or handoff, or by `reconcileAssignedTopics` once the durable route stops naming this worker — that last one is what releases an adopted flood | The authoritative "what I own" set; drives `isAssigned` and load |
|
|
342
|
+
| `knownTopics` | `WorkerClusterRuntime` | `topicKey` | Plaintext `topic` | FIFO scan capped at 500 that skips owned keys and the key being remembered, so an all-owned cache lets the cap slip | The reverse-lookup cache; also the only source of plaintext in storage-less mode |
|
|
342
343
|
| Storage `worker:` | persisted | `clusterHash:…:worker:{workerId}` | JSON `WorkerRecord` | Heartbeat refresh; pruned after `workerTtlMs` | Cross-tab liveness discovery |
|
|
343
344
|
| Storage `route:` | persisted | `clusterHash:…:route:{topicKey}` | JSON `WorkerRoute` | Created/stamped by subscriber; pruned when no subscribers + TTL expired | Cross-tab owner mapping |
|
|
344
345
|
| Storage `subscriber:` | persisted | `clusterHash:…:subscriber:{topicKey}:{tabId}` | JSON `TopicSubscriberRecord` | Written per Tab subscription; pruned when the Tab dies | Cross-tab subscriber intent |
|
|
@@ -22,7 +22,7 @@ Only `pnpm bench:browser` / `pnpm bench:compare` / `pnpm bench:trend` stay local
|
|
|
22
22
|
3. Gate dependency security: `pnpm audit --registry=https://registry.npmjs.org` (the configured mirror registry lacks the audit endpoint; CI runs it on the public registry in the verify job). Fail the release on any known-vulnerability advisory; `pnpm-workspace.yaml` overrides pin patched ranges.
|
|
23
23
|
4. Gate browser benchmark regressions: run `pnpm bench:browser` (twice at minimum; the gate compares the newest report against the median of the same metric in up to the five preceding archived reports, **and additionally requires the new value to exceed the highest of those samples**) and then `pnpm bench:compare --fail-above-pct 50`. The median baseline exists because the in-page hot-path metrics alternate between a fast and a slow mode on identical code — two consecutive runs of `dedup1000Ms` measured 12.7 ms then 25.6 ms, and a single noisy previous report could fail the documented ceiling with no code change at all. The second leg exists because a median over an alternating sample is only stable while the modes stay mixed: when several consecutive reports land in the same mode the median itself jumps, which is how one comment-only tree read +121% against one baseline and −56.7% against another minutes apart. A metric excused by that leg is printed under `within-baseline, not gated` rather than passing silently — measured on the current archive, `publish/dedicated/perMessageMs`, `publish/shared/perMessageMs` and `databus/publishBatch1000Ms` were all inside their own five-report range, so treat that list as the metric's real resolution, not as a clean bill. `publish/dedicated/perMessageMs` is noisy the same way: two consecutive runs of identical code measured 49.9 ms then 71.1 ms, failing the gate at +75.7% while `dedup1000Ms` and `traceAndPublish1000Ms` *improved* in the same report — that single-metric-up-everything-else-down shape is the noise signature, and the next run reported 49.4 ms and passed. Before accepting or acting on a failure, re-run and check the spread; if the change touches a hot path, size it directly (a micro-benchmark of the 0.20.95 bounded-map rewrites measured 80–86 ns/op across all three variants, i.e. inside run-to-run variance). A baseline shift (e.g. a metric becoming real instead of a no-op) is an expected one-time failure. Refresh the long-run trend doc with `pnpm bench:trend` and commit it when the tables change. **Re-running a failure can manufacture its own excuse, and that was measured.** `bench:compare`'s baseline — both the median and the maximum leg — is drawn from the most recent archived reports, and every `bench:browser` run appends to that same archive, so the samples you add while investigating a failure become the baseline that judges the next attempt. On 2026-09-24, at host load averages 7.7–15.1 with a zero non-comment `src/` diff in the tree, the first two runs measured `publish/dedicated 77.3 ms` and `publish/shared 67.7 ms` against a ~38/~34 ms fast mode and failed the 50% ceiling; five further re-runs reported **OK**, because the baseline median had slid to `70.6`. One clean run after taking those samples out of the archive showed every metric rising together (`dedicated +92.5%`, `shared +99.2%`, `dedup +43.4%`, `trace +21.0%`), which is the contention signature and the inverse of the single-metric-up shape above. So read the load average *before* re-running, and when a suspect failure occurs on a loaded host, record it as deferred with its numbers and move the off-mode samples aside instead of letting them into the baseline — and do not regenerate `docs/benchmarks.md` from them. **The standing decision, recorded at 0.21.17 (the fifth release in that state): when no quiet window exists across a cycle, defer the sample with its load numbers instead of taking it on a loaded host.** The deferral is what keeps `docs/benchmarks.md` stale, and staleness-by-recorded-opportunity is the intended outcome of this step, not a gate that passed quietly; what would not be acceptable is a loaded sample entering the archive, because that becomes the baseline the next release is judged against.
|
|
24
24
|
5. Confirm the package contains only intended files with `npm pack --dry-run --json`.
|
|
25
|
-
6. Commit on a feature branch, push that branch, and merge its green PR using squash or fast-forward (no merge commit). Fetch the merged commit, tag that exact commit, and push only the specific version tag; never push `main`/`master` directly or force-push. The workflow runs `node scripts/verify-release-version.mjs` to require `RELEASE_TAG` to equal `v` + the package version and to require exactly one non-empty CHANGELOG section.
|
|
25
|
+
6. Commit on a feature branch, push that branch, and merge its green PR using squash or fast-forward (no merge commit). Fetch the merged commit, tag that exact commit, and push only the specific version tag; never push `main`/`master` directly or force-push. The workflow runs `node scripts/verify-release-version.mjs` to require `RELEASE_TAG` to equal `v` + the package version and to require exactly one non-empty CHANGELOG section. The same step compares every version heading in `CHANGELOG.md` against the registry's own `time` map and refuses a release record that names a version npm never had — but only from `0.20.85` upward, because below that floor 40 sections name versions the registry never recorded, 27 of them tagged (measured on the day `v0.21.33` published; re-derive with `npm view cross-tab-worker-databus time --json`), and the gate exists to stop a new hole rather than to litigate history. The version being tagged is exempt, since it legitimately cannot be on npm yet, and a registry read that fails prints a skip warning and exits 0: refusing a good release over one transient HTTP call is the failure mode the published-consumer ceiling was sized to avoid, so only a *confirmed* absence is fatal.
|
|
26
26
|
|
|
27
27
|
## Security and dependency scanning
|
|
28
28
|
|
|
@@ -42,6 +42,6 @@ For a manual release (no `NPM_TOKEN` in the workflow), run `npm publish --access
|
|
|
42
42
|
2. Install the published tarball or version in a clean consumer and import the root plus every public subpath.
|
|
43
43
|
3. Record the result in the release notes. Do not advance to `1.0.0` until the public API and protocol deprecation policy are explicitly frozen.
|
|
44
44
|
|
|
45
|
-
The tagged-release workflow already ran the consumer verification above. Run `PUBLISHED_VERSION=<version> pnpm verify:published` by hand only when you need an offline repeat. The workflow's 12-minute ceiling is not padding, and the number is a sum of two measured lags. First: the registry records the publish minutes after `npm publish` returns — the ack→`time[<version>]` gap measured on 0.21.27 through 0.21.
|
|
45
|
+
The tagged-release workflow already ran the consumer verification above. Run `PUBLISHED_VERSION=<version> pnpm verify:published` by hand only when you need an offline repeat. The workflow's 12-minute ceiling is not padding, and the number is a sum of two measured lags. First: the registry records the publish minutes after `npm publish` returns — the ack→`time[<version>]` gap measured on 0.21.27 through 0.21.33 was 74.8–310.0 s, and 248.7 / 96.8 / 74.8 / 310.0 / 127.2 / 76.1 / 75.5 s in version order (read `time[<version>]` from the packument and compare it with the `Publish to npm` step's completion time). Second: the packument that `npm pack` resolves against is served with `cache-control: public, max-age=300`, so a copy of it anywhere in the path is allowed to be up to five minutes stale, and resolution cannot be trusted to beat one cache lifetime after a write that lands inside that window. Which copy — npm's local cache or an intermediate — served the stale views below is *not* established, and the counter-observation this note used to offer against a purely local account does not survive being read carefully, because it joins two machines: the 21:44:34Z "fresh fetch" was a `npm pack` run on a laptop, while the 1 s green at 21:47:10Z was a *new runner job*, and a new job's npm cache starts empty — which is what the local account predicts rather than what contradicts it. What a purely-local account still cannot explain is one specific reading: the runner's own `ETARGET` at 21:45:07Z — 364 s after the step that opened its first poll (21:39:03Z), so ~60 s *after* the point where a copy taken then must have gone stale (21:44:03Z, give or take the second the request actually left). The ceiling is therefore arithmetic rather than a model: worst-case ack→`time[]` gap plus one cache lifetime. That sum is not theoretical: the previous 6-minute ceiling was exhausted by a *successful* publish, the 0.21.30 tag run spending its whole 360 s budget (48 × 7.5 s) on `ETARGET` while that version's tarball HEAD and a local `npm pack` had both already succeeded, and the same step 123 s later taking 1 s. The 0.20.89 run had shown the same shape against that release's 2-minute budget. So a long retrying verify is normal propagation, not an unusually slow mirror — raise `PUBLISHED_VERIFY_ATTEMPTS` / `PUBLISHED_VERIFY_DELAY_MS` further only if the ack→`time[]` gap has itself grown. Note the asymmetry when repeating by hand: `verify-published-consumer.mjs` defaults to `6` attempts × `5_000` ms — 30 seconds, not 12 minutes — because the tag run passes the larger pair as env rather than the script owning it. So a manual repeat can report `ETARGET` on a version whose CI run was green, which reads like a failed publish and is not one; reproduce the CI budget explicitly with `PUBLISHED_VERSION=<version> PUBLISHED_VERIFY_ATTEMPTS=96 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`, or judge a manual failure against the 30 s budget you actually ran. Read the step's duration as a diagnostic rather than a mood: the five green tag runs from 0.21.25 to 0.21.29 took 307, 304, 305, 304 and 304 s, 0.21.31's took 308 s and 0.21.32's and 0.21.33's took 304 s each — eight samples in a 5-second band, which is what one 300 s cache lifetime plus a few seconds of command time predicts (take the numbers from each release run's `Verify published npm consumers` step, `steps[].started_at`/`completed_at` from the same `gh api` call). 0.21.31, 0.21.32 and 0.21.33 are the first three releases to run under the raised 720 s ceiling, and their three lags split differently, which is the useful contrast: 127.2 s of record plus ~181 s of cache for the one, 76.1 s of record plus ~228 s before the runner saw it for the next, and 75.5 s of record plus ~229 s for the third — on 0.21.32 a `no-cache` packument read from a laptop reported the new `latest` 151 s in, while the runner's own poll kept failing until 304 s, i.e. one lifetime after *its* first fetch. So the sample that set the previous ceiling has not been beaten: if the *ack→`time[]`* figure grows past 310 s, raise `PUBLISHED_VERIFY_ATTEMPTS` again; a verify that finishes in seconds means whatever copy it read already carried the new version.
|
|
46
46
|
|
|
47
47
|
**Do not adjudicate a publish from `dist-tags.latest`.** The package document endpoint and the tarball URL are two different read paths, and their timestamps are worth more than the impression they first give. Read during the 0.21.30 release, in order: `npm publish` returned success at `21:39:03Z`; a `curl -s -H "Cache-Control: no-cache" https://registry.npmjs.org/<pkg>` at `21:43:15Z` reported `latest` still on the previous version, no `0.21.30` in `versions`, and no `time['0.21.30']`; npm's own stamp for that version is `21:44:12.987Z` and the document's `last-modified` is `21:44:14 GMT`. So the 21:43:15 read was **not** a replica refusing an artifact that already existed — the registry had not finished recording the publish, and `no-cache` could not have made it see a version that did not exist yet. Absence from `versions` and from `latest`, minutes after a green publish step, is the expected state of a successful release. The genuine read-path disagreement came 60 s later: between `21:44:14Z` and `21:44:35Z`, `curl -I …/-/<pkg>-0.21.30.tgz` returned `HTTP 200` and a local `npm pack <pkg>@0.21.30 --registry https://registry.npmjs.org` completed and wrote the tarball, while the workflow runner's own `npm pack` kept returning `ETARGET` until it exhausted its budget at `21:45:07Z`. Same version, two machines, opposite answers a minute apart. To answer "did the publish happen", HEAD the tarball URL and try the pack — those reach the artifact — and try it **from the place that is failing**, because "fetchable" is a per-machine answer; read `latest` only for the question "which version do consumers get by default", which is a different one and settles later. `npm view <pkg> version` adds a third path on top: it can be served from npm's *local* packument cache, so on a machine that queried the registry before the publish it can return the superseded version even after the global `latest` has moved (that is why this gate resolves its target from `PUBLISHED_VERSION` and refuses an inferred version that disagrees with `package.json`). Never re-push, move, or replace a tag because a metadata read looked stale; the tag is immutable once published.
|
package/docs/roadmap.md
CHANGED
|
@@ -1,6 +1,24 @@
|
|
|
1
1
|
# Roadmap
|
|
2
2
|
|
|
3
|
-
0.21.
|
|
3
|
+
0.21.34 was released on September 25, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
|
|
4
|
+
|
|
5
|
+
## 0.21.34 delivered scope
|
|
6
|
+
|
|
7
|
+
- **A tag can now be refused because the release record names a version npm never had.** `scripts/verify-release-version.mjs` reads the packument's `time` map beside the checks it already made and fails when a CHANGELOG section at or above `firstGatedRelease = 0.20.85` has no registry record. The in-flight release is exempt, a duplicated section reports once, and a failed registry read warns and skips rather than turning a good release red — the deliberate half of the design. The floor comes from a count, not taste: 40 of the 164 sections name unpublished versions (`0.9.0`, each minor's first patch from `0.12.0` to `0.18.0`, all ten `0.19.x`, `0.20.0`–`0.20.5`, `0.20.54`, `0.20.55`, `0.20.69`, `0.20.72`–`0.20.84`; 1 + 7 + 10 + 6 + 2 + 1 + 13 = 40) — 41 counting the release in flight, which is why the gate exempts it — and every one sits below it, while the 47 sections from `0.20.85` through `0.21.33` are all present (that count is this tag's own reading — it rises by one with every release, and the script prints it). Four mutants, four named tests, one failure each.
|
|
8
|
+
- **One eviction skip had no test that could see it.** `rememberTopic()` skips owned keys *and* the key being remembered; deleting the second term left all 944 tests green. It is reachable only when every older entry is owned, because a fresh `Map.set` lands at the back of the insertion-ordered Map and that is the one case where the front-scan reaches it — and there the mutant throws away the mapping the call exists to install. The new case stages 500 adopted peer SUBSCRIBE frames plus one PUBLISH and fails at `expected [ 'owned.0', …(498) ] to include 'evict.extra'`; the owned term keeps its own pre-existing case, so both skips are individually attributed. Two earlier designs are recorded in the test's comment because both were plausible and neither reached the leg: an inbound SUBSCRIBE cannot produce an unowned entry, and re-remembering a key already present cannot overflow the cap.
|
|
9
|
+
- **Three shipped sentences about caps described protections the code does not provide.** `MAX_KNOWN_TOPICS = 500` was documented as stopping a malicious peer from exhausting memory through control messages; measured, 1,200 peer `CONTROL/SUBSCRIBE` frames grew `knownTopics` and `assignedTopics` to 1,200, because each frame is adopted, adoption makes its key owned, and the loop then refuses to drop anything — one reconcile tick took both back to `0`, so the flood's bound is the sweep and the cap's bound is over unowned entries. `trace.ts` credited both of its caps with guarding "a single misbehaving topic", when `MAX_PENDING_TOPICS` is an admission gate over *distinct* topics (1,001 topics → 1,000 queues, while an admitted topic still grows to 256) and the `topics` Set carries neither cap by design, bounded by the window flush. And the identifier table in the same architecture doc still restated the eviction rule in its pre-correction form while the row beside it omitted `reconcileAssignedTopics`, the only path that ends a flood. All of it is fixed in both languages, and the `src/` comments now point at the loop and at the tests rather than restating the rule twice.
|
|
10
|
+
- **A candidate test that duplicates an existing one is deleted, not kept.** The trace caps looked unpinned because the grep used the constants' names, and the two cases that do pin them write the numbers in a comment and never mention the identifiers. Both new cases were written, then the mutation run reported that deleting the admission guard failed **two** tests — the new one and `caps the number of topics tracked for pending receives`, which uses more inputs than the new one did. They were removed; the comment cites the existing names. The release therefore adds one test (the eviction pin) and removes none.
|
|
11
|
+
- **The publication samples are seven gaps and eight durations, and the ceiling's derivation is unchanged.** `0.21.33`: ack `00:31:20Z`, registry record `00:32:35.519Z` (**75.5 s**), verify step **304 s** — the eighth green sample in the 304–308 s band and one 300 s lifetime plus command time from that runner's own first fetch. 75.5 s does not beat the 310 s that sizes the 720 s budget, so `maxMeasuredAckToRecordMs` stays put and `tests/workflows.test.ts` passes unmodified.
|
|
12
|
+
- **What did not move.** No library code, export, option, default, frame or storage key changed; `verify:compat`, `verify:types` and `verify:pack` run against `v0.21.33`, and the arm ledger and coverage aggregates are `0.21.33`'s. The suite is 37 files / 950 tests. The only new blocking behavior is inside the release workflow's own version gate, which skips itself when the registry read fails.
|
|
13
|
+
|
|
14
|
+
## 0.21.33 delivered scope
|
|
15
|
+
|
|
16
|
+
- **A measurement cited as evidence against a model turned out to join two machines.** The publish-lag prose argued that a purely-local npm cache account was refuted because "the retry resolved before a fresh 21:44 fetch's 300 s lifetime had run out". Against the run records, the fresh read was a laptop's `npm pack` at 21:44:35Z and the 1 s green was a **new runner job** at 21:47:10Z — and a new job's cache starts empty, which is what the local model predicts rather than what refutes it. The claim is withdrawn, and what a local account still cannot explain is stated as the single reading it is: the runner's own `ETARGET` at 21:45:07Z, 364 s after its poll loop opened at 21:39:03Z and ~60 s after a copy taken then must have expired. The verdict stays *not established*.
|
|
17
|
+
- **`0.21.32` supplied the model's cleanest sample while this was being written.** Ack 23:34:46Z, registry record 23:36:02.091Z (**76.1 s**), a laptop reading the new `latest` at 151 s with `no-cache`, and the runner's blocking step finishing at **304 s** — one lifetime plus command time, measured from its own first fetch. The verify-duration band is now seven green samples at 304–308 s; both sample lists were extended in both languages, in the workflow comment and in the test that enforces the floor.
|
|
18
|
+
- **Three of those numbers named the wrong quantity, and all three went before the tag.** "the second-smallest of the **seven** now listed" had borrowed the duration list's size for the gap list, which carries six values (the seven is 307 / 304 / 305 / 304 / 304 / 308 / 304 s of *step duration*), and the sentence's own parenthesis already enumerated six. Three copies described 0.21.30 as spending "its whole **364 s** budget", but that run's ceiling was 360 s (48 × 7.5 s) and 364 s is only the span from its first poll to its last `ETARGET` — a budget and a reading written as one number. And `docs/progress.md` still carried the superseded first draft of that span, "about 5 min 40 s after the fetch that should have gone stale by 21:44:05Z", matching neither the 364 s span nor the ~60 s past expiry every other copy states. Checking the first of those meant sampling the two releases below the gap list's stated range for the first time: 0.21.25 is **157.8 s** (ack 17:56:53Z, record 17:59:30.781Z) and 0.21.26 **96.1 s** (ack 18:41:40Z, record 18:43:16.084Z) — and their verify steps come back at 307 s and 304 s, exactly the two values the duration list already carries, so the run↔version attribution is confirmed by a number already on file rather than by the new ones. Eight gaps now exist, none beats 310.0 s, and the two new readings are recorded here and in `CHANGELOG.md` rather than added to every restatement of the list, because a fifth copy of a set of numbers is a fifth thing to keep in sync.
|
|
19
|
+
- **What did *not* change, and the check that proves it.** 76.1 s does not beat the 310 s that sizes the 720 s ceiling, so `maxMeasuredAckToRecordMs` stays at 310 s and `tests/workflows.test.ts` passes 6/6 unmodified — widening the sample list without moving the derivation is the result this release was looking for, not a reason to raise the budget again.
|
|
20
|
+
- **History corrected by pointer, not by rewrite.** `CHANGELOG.md`'s `0.21.31` entry and both `docs/roadmap.md` copies still carry the sentence they got wrong, each with a note naming `0.21.33` as what superseded it, so the record reads as the sequence it actually was. `AGENTS.md` gained the general rule beside the one it already had: before citing an observation against a model, check both halves came from the same machine and the same path.
|
|
21
|
+
- **What did not move.** No library code, export, option, default, frame or storage key changed; `verify:compat`, `verify:types` and `verify:pack` run against `v0.21.32`, and the arm ledger and coverage aggregates are `0.21.32`'s (46 zero-count arms of 1951; 99.02 / 97.64 / 99.27 / 99.69).
|
|
4
22
|
|
|
5
23
|
## 0.21.32 delivered scope
|
|
6
24
|
|
|
@@ -12,7 +30,7 @@
|
|
|
12
30
|
|
|
13
31
|
## 0.21.31 delivered scope
|
|
14
32
|
|
|
15
|
-
- **The release gate that failed on a good publish, sized by measurement instead of by feel.** `0.21.30`'s tag run consumed the whole 48 × 7.5 s published-consumer budget on `ETARGET` and then passed in 1 s when the same tag was re-run. The ceiling turns out to be a sum of two lags, both now measured: `npm publish`'s ack precedes the registry's own `time[<version>]` record by 74.8 s (0.21.29), 96.8 s (0.21.28), 248.7 s (0.21.27) and 310.0 s (0.21.30), and the packument `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 second term is also what the three preceding green runs had been reporting with their suspiciously identical 305 / 304 / 304 s — a regularity that reads as noise until something explains it. The budget is now 96 × 7.5 s = 720 s, clearing 610 s. Which copy served the stale views is deliberately left open: a purely npm-local-cache account predicts the retry should have waited for the same 300 s object and it did not.
|
|
33
|
+
- **The release gate that failed on a good publish, sized by measurement instead of by feel.** `0.21.30`'s tag run consumed the whole 48 × 7.5 s published-consumer budget on `ETARGET` and then passed in 1 s when the same tag was re-run. The ceiling turns out to be a sum of two lags, both now measured: `npm publish`'s ack precedes the registry's own `time[<version>]` record by 74.8 s (0.21.29), 96.8 s (0.21.28), 248.7 s (0.21.27) and 310.0 s (0.21.30), and the packument `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 second term is also what the three preceding green runs had been reporting with their suspiciously identical 305 / 304 / 304 s — a regularity that reads as noise until something explains it. The budget is now 96 × 7.5 s = 720 s, clearing 610 s. Which copy served the stale views is deliberately left open: a purely npm-local-cache account predicts the retry should have waited for the same 300 s object and it did not. *(Superseded by `0.21.33`: that inference joined a laptop's `npm pack` read with a new runner job's 1 s green, i.e. two machines, and a new job starting with an empty cache is what the local account predicts. Its surviving anomaly is one reading — the runner's `ETARGET` ~60 s after its own copy must have expired — and 0.21.32's 304 s verify is the model's cleanest sample, with the band now seven releases wide at 304–308 s.)*
|
|
16
34
|
- **A floor that blessed the value which had just failed.** `tests/workflows.test.ts` asserted `totalMs >= 5 * 60 * 1000`, so the 360 s budget that had just turned a good release red satisfied the gate whose only job is to prevent that, and a further lowering would have gone unnoticed. The floor is now the two terms above, as named constants beside the rule for re-deriving each. Mutation-checked in both directions: reverting the workflow to 48 fails exactly that test with a message naming both lags, and the same floor rejects the 360 s budget that failed here and the 120 s one 0.20.89 exhausted.
|
|
17
35
|
- **A note about that failure, retracted against its own timestamps.** The checklist paragraph written during the same release said the package document endpoint and the tarball URL had disagreed "in the same minute". The readings it quotes put the stale-document read at 21:43:15Z and the registry's record of the version at 21:44:12.987Z — so that read was not lagging an artifact that already existed; it was correctly reporting a publish the registry had not finished writing, and no `no-cache` request could have helped. The genuine disagreement is one machine fetching the tarball by 21:44:35Z while the runner was still on `ETARGET` at 21:45:07Z, which is why the text now says to probe from the machine that is failing, and why absence from `versions`/`latest` minutes after a green publish step is documented as the *expected* state of a successful release.
|
|
18
36
|
- **`wildcardPublishCache`: the per-topic map the documented cap does not cover, and why a cap is not free.** It maps a concrete topic to the local wildcard pattern that matched it, or `null` for "scanned, nothing matched"; it has no bound, and is cleared only by the two lifecycle teardowns beside each `routeOwnerCache.clear()`. Measured: 1,200 `publish()` calls on distinct topic names leave `knownTopics` at its 500-entry cap and this map holding 1,200. The cost of evicting either half is asymmetric — dropping a *pattern* re-runs the first local dispatch the entry exists to prevent, dropping a `null` re-scans and, if a wildcard was assigned in between, hands that publication the fan-out a first one gets — so the note records that bounding it needs a rule about which half may be forgotten rather than a number, and `docs/architecture.md` says the same in the paragraph after "Cap and eviction".
|
|
@@ -611,6 +629,10 @@ The line continues the async-callback isolation audit: every fix below binds a c
|
|
|
611
629
|
|
|
612
630
|
- Added peer protocol capability discovery to cluster snapshots and diagnostics. Current runtimes advertise protocol version 1; legacy peers remain visible as `null`.
|
|
613
631
|
|
|
632
|
+
## 0.20.68 delivered scope
|
|
633
|
+
|
|
634
|
+
- Added protocol version metadata and compatibility behavior for mixed-version cluster peers.
|
|
635
|
+
|
|
614
636
|
## 0.20.67 delivered scope
|
|
615
637
|
|
|
616
638
|
- Added bounded unknown protocol message diagnostics on `WorkerClusterRuntime` and `CrossTabDataBus.getDiagnostics()`, including count and last message type while preserving safe ignore behavior.
|
|
@@ -989,10 +1011,6 @@ The line continues the async-callback isolation audit: every fix below binds a c
|
|
|
989
1011
|
- Publication metadata compatibility coverage across WebSocket, Centrifuge, Worker boundaries, and browser E2E.
|
|
990
1012
|
- Service Worker transport decision: remain deliberately unimplemented until a stable connection-lifetime contract exists across target browsers.
|
|
991
1013
|
|
|
992
|
-
## 0.20.68 delivered scope
|
|
993
|
-
|
|
994
|
-
- Added protocol version metadata and compatibility behavior for mixed-version cluster peers.
|
|
995
|
-
|
|
996
1014
|
## 0.20.69 candidates
|
|
997
1015
|
|
|
998
1016
|
1. ~~Publish a peer capability matrix and expose SDK/backend/transport identity in diagnostics.~~ Delivered: `getDiagnostics()` carries protocol version, unknown-message stats, peer protocol versions, and transport identity; `getHealthSummary()`/`getMetrics()` now ship live trace metrics and sink state.
|
package/docs/zh/architecture.md
CHANGED
|
@@ -197,14 +197,15 @@ BroadcastChannel CONTROL
|
|
|
197
197
|
1. **无 storage 退化路径**。localStorage 不可用时（降级模式），`readRoute()` 和 `readSubscriberTabIds()` 没有持久化记录可查，只能从内存状态重建路由——但需要从 `topicKey` 反推出原始 `topic`。没有 `knownTopics`，即使 worker 仍持有该 topic，被淘汰的 key 也会让 `readRoute()` 静默返回 `null`。
|
|
198
198
|
2. **避免每次 reconcile 重复哈希**。每次 reconcile 循环遍历 `subscribedTopics`，对每个 topic 调用 `rememberTopic`。缓存总是无条件更新（哈希很便宜，命中/未命中开销可忽略），但反向映射对无 storage 路径至关重要。
|
|
199
199
|
|
|
200
|
-
**上限与淘汰**。缓存上限为 `MAX_KNOWN_TOPICS = 500`
|
|
200
|
+
**上限与淘汰**。缓存上限为 `MAX_KNOWN_TOPICS = 500` 条，而这个上界管住的是本 worker **不持有**的那些条目。每个被处理的 `CONTROL` 消息都会调用 `rememberTopic`，而淘汰扫描一路走到缓存末尾都没找到非持有的条目时，它宁可什么都不删——持有的 key 必须留下，因为无 storage 的读取路径只能从这张表里还原它们的明文。所以一个对任意 topic 刷 `CONTROL/SUBSCRIBE` 的 peer 并不被这个上限挡住：这样的帧每个都会被收养，收养就让它变成持有的，因而不可淘汰。实测 1,200 条 peer SUBSCRIBE 帧：`knownTopics` 连同 `assignedTopics` 一起涨到 1,200 条，一轮 reconcile 又把两者都带回 `0`——因为一次没有可确认 route 的收养本来就是临时的。对这种洪水，内存的界是清扫，不是上限。
|
|
201
201
|
|
|
202
202
|
有一张形状相同的记忆表后来是被**直接删掉，而不是加上上限**，理由值得留下：`wildcardPublishCache` 把具体 topic 映射到匹配它的本地通配模式（或用 `null` 表示"扫描过了，没有匹配"），本 Worker 每发布到一个新的 topic 就多一条记录，而且完全没有限界。实测：对 1,200 个互不相同的 topic 调用 `publish()` 之后，`knownTopics` 仍是 500 条，而这张表存有 1,200 条。它当时定不下一条淘汰规则，因为两种取值都不能随便忘——而这个问题本身就问错了。存下来的取值其实什么也没决定：两种形状都只被当作"这个 topic 我扫过没有"来读，唯一的路由影响是某个 topic 的*第一次*发布在匹配到通配模式时会在本地分发，并且完全不查持久化的 route。于是一个 Worker 持有 `chat.*`、对端 Worker 具体持有 `chat.room.1` 时，从通配持有者发出的三次发布是 `1,0,0` 留在自己这里、`0,1,1` 送到 owner——第一次根本没被转发出去，而投递语义是 at-most-once。所以这条快速路径已经删掉，所有非本地持有的发布现在都经由 route 决定 owner，那张表也一起消失了：它的无界增长只是这个优化本身的副作用，而这个优化本身就是 bug。
|
|
203
203
|
|
|
204
|
-
淘汰策略为 FIFO（按插入顺序，即 Map
|
|
204
|
+
淘汰策略为 FIFO（按插入顺序，即 Map 迭代顺序）。当缓存超过上限时，扫描删掉它**被允许**删的第一个条目然后停下——回到上限之内只需一次删除，多删只会白白丢掉还能解析的 topic：
|
|
205
205
|
|
|
206
|
-
- **当前 worker 仍持有的 key
|
|
207
|
-
-
|
|
206
|
+
- **当前 worker 仍持有的 key 不会被淘汰**（扫描里 `this.assignedTopics.has(candidate)` 这一项跳过），因为无 storage 的 `readRoute` 路径依赖它。
|
|
207
|
+
- 本次正在记忆的 key 不会被自己这次调用淘汰（同一个跳过里的 `candidate === topicKey` 这一项）。新写入的 `Map.set` 落在末尾，所以扫描只有在本轮之前的条目全部被持有时才会走到它——而在那里删掉它，等于丢弃本次调用本来要建立的映射。由 `tests/cluster.test.ts` 的 "keeps the topic it is remembering when the cache is full and every older entry is owned" 钉住。
|
|
208
|
+
- 没有任何条目可选时，上限失守而不是淘汰一个持有的 key：持有比有界缓存更重要，而失守的上限在 `getSnapshot().knownTopics` 里看得见，丢失的映射看不见。
|
|
208
209
|
- 读取不会提升 recency，因此这不是真正的 LRU。哈希足够便宜，反向查找未命中只需重新计算一次 key。
|
|
209
210
|
|
|
210
211
|
**`isAssigned` 绕过缓存**。`isAssigned(topic)` 直接调用 `createOpaqueKey(topic)` 而非 `rememberTopic()`。这是刻意的：`isAssigned` 是只读查询，不是状态变更，因此不应填充 `knownTopics`（那可能淘汰无 storage 路径需要的条目）。它也优先使用同步的 `assignedTopics` Map 而非从 storage 读取路由，避免与 `BatchingStorageWriter` 的 flush 窗口产生竞态。
|
|
@@ -227,14 +228,14 @@ BroadcastChannel CONTROL
|
|
|
227
228
|
| 收到 `CONTROL/UNSUBSCRIBE` | 不做直接删除 | `rememberTopic` 仍会缓存该 topic；路由不再指向本 worker 后由 `reconcileAssignedTopics` 移除 |
|
|
228
229
|
| `reconcileAssignedTopics` | 如未订阅且未持有则 `delete(topicKey)` | 路由不再指向我们——除非仍是 subscriber 否则清理 |
|
|
229
230
|
| `stop()` | `clear()` | 完全销毁 |
|
|
230
|
-
| FIFO 淘汰（下次 `rememberTopic` 调用时） |
|
|
231
|
+
| FIFO 淘汰（下次 `rememberTopic` 调用时） | 从最老的条目往后扫描，`delete` 第一个既不在 `assignedTopics` 中、也不是本次正在记忆的 key，然后停止 | 缓存超出 `MAX_KNOWN_TOPICS`；持有的 key 与新 key 都被跳过，所以所有条目都被持有时上限会失守 |
|
|
231
232
|
|
|
232
233
|
**无 storage 退化依赖**。当 `this.storage` 为 `null`（降级模式）时，`readRoute()` 和 `readSubscriberTabIds()` 无法查询持久化记录，只能从内存状态重建路由：
|
|
233
234
|
|
|
234
235
|
- `readRoute(topicKey)` → 用 `knownTopics.get(topicKey)` 恢复明文 topic，然后检查 `subscribedTopics.has(topic)` 或 `assignedTopics.has(topicKey)` 判断本 worker 是否是 owner。
|
|
235
236
|
- `readSubscriberTabIds(topicKey, workers)` → `knownTopics.get(topicKey)` 恢复明文 topic，然后检查 `subscribedTopics.has(topic)`——如果本 worker 是 subscriber，那就是唯一的 subscriber（无 storage 意味着无跨 Tab 协调）。
|
|
236
237
|
|
|
237
|
-
这就是为什么 `assignedTopics` 守卫 FIFO 淘汰：淘汰仍持有的 key 会在无 storage 模式下静默破坏 `readRoute()`，导致 `isAssigned()` 与 `readRoute()`
|
|
238
|
+
这就是为什么 `assignedTopics` 守卫 FIFO 淘汰：淘汰仍持有的 key 会在无 storage 模式下静默破坏 `readRoute()`，导致 `isAssigned()` 与 `readRoute()` 结果不一致。扫描同时跳过本次调用带进来的那个 key，理由同构——删掉它等于丢弃这次调用本来要建立的映射——而它只有在更早的条目全部被持有时才会走到那里，因为新写入的 `set` 落在插入有序 `Map` 的末尾。
|
|
238
239
|
|
|
239
240
|
### 一次订阅和消息分发流程
|
|
240
241
|
|
|
@@ -306,8 +307,8 @@ console.table(__bus.getClusterSnapshot().routes)
|
|
|
306
307
|
| `topicHandlers` | `CrossTabDataBus` | 明文 `topic` | `Set<handler>` | 应用 `subscribe`/`unsubscribe` 增删；最后一个 handler 离开时删除条目 | 引用计数应用层 handler；属于业务层职责 |
|
|
307
308
|
| `transportSubscribedTopics` | `CrossTabDataBus` | 明文 `topic` | 标记 | 断开时清空；重连时从 `assignedTopics` 重放 | 跟踪真实 transport 连接实际持有的订阅；随连接一起消亡 |
|
|
308
309
|
| `subscribedTopics` | `WorkerClusterRuntime` | 明文 `topic` | 标记 | 第一个本地 handler 订阅时增长；最后一个退出时收缩 | Tab 的持久订阅意图，transport 故障后仍保留 |
|
|
309
|
-
| `assignedTopics` | `WorkerClusterRuntime` | `topicKey` | 明文 `topic` | 收到 `CONTROL/SUBSCRIBE` 时设置；`CONTROL/UNSUBSCRIBE`
|
|
310
|
-
| `knownTopics` | `WorkerClusterRuntime` | `topicKey` | 明文 `topic` | FIFO
|
|
310
|
+
| `assignedTopics` | `WorkerClusterRuntime` | `topicKey` | 明文 `topic` | 收到 `CONTROL/SUBSCRIBE` 时设置；`CONTROL/UNSUBSCRIBE` 或交接时清除，或由 `reconcileAssignedTopics` 在持久 route 不再指向本 worker 后收回——最后这一条才是收养洪水的出口 | "我拥有什么"的权威集合；驱动 `isAssigned` 和负载 |
|
|
311
|
+
| `knownTopics` | `WorkerClusterRuntime` | `topicKey` | 明文 `topic` | FIFO 扫描上限 500，会跳过持有的 key 与本次正在记忆的 key，因此所有条目都被持有时上限会失守 | 反查缓存；也是无 storage 模式下明文的唯一来源 |
|
|
311
312
|
| 存储 `worker:` | 持久化 | `clusterHash:…:worker:{workerId}` | JSON `WorkerRecord` | 心跳刷新；超过 `workerTtlMs` 被清理 | 跨 Tab 存活发现 |
|
|
312
313
|
| 存储 `route:` | 持久化 | `clusterHash:…:route:{topicKey}` | JSON `WorkerRoute` | 由订阅方创建/盖章；无订阅者且 TTL 过期时清理 | 跨 Tab owner 映射 |
|
|
313
314
|
| 存储 `subscriber:` | 持久化 | `clusterHash:…:subscriber:{topicKey}:{tabId}` | JSON `TopicSubscriberRecord` | 每次 Tab 订阅写入；Tab 死亡时清理 | 跨 Tab 订阅意图 |
|
|
@@ -23,7 +23,7 @@
|
|
|
23
23
|
4. 浏览器基准回归门禁：运行 `pnpm bench:browser`（至少两次；门禁将最新报告与之前最多五份归档报告中同一指标的中位数比较，**并且额外要求新值超过这些样本中的最大值**），随后执行 `pnpm bench:compare --fail-above-pct 50`。采用中位数基线是因为页内热路径指标在同一份代码上会在快/慢两档之间来回跳——`dedup1000Ms` 相邻两次实测分别为 12.7 ms 与 25.6 ms，只看"上一份报告"时，一次偶发噪声就能在无代码改动的情况下击穿既定上限。第二个条件则是因为：在两档交替的样本上，中位数只有当两档保持混合时才稳定——一旦连续几份报告落在同一档，中位数本身就会跳变，这正是同一份纯注释改动在一版基线前读出 +121%、几分钟后在另一版基线前读出 −56.7% 的原因。被该条件放过的指标会打印在 `within-baseline, not gated` 下，而不是静默通过——在当前归档上实测，`publish/dedicated/perMessageMs`、`publish/shared/perMessageMs` 与 `databus/publishBatch1000Ms` 三项都落在各自五份报告的区间内，因此应把这份清单读作该指标的真实分辨率，而不是一张合格证。`publish/dedicated/perMessageMs` 同样如此：同一份代码相邻两次实测为 49.9 ms 与 71.1 ms，令门禁以 +75.7% 失败，而同一份报告里 `dedup1000Ms` 与 `traceAndPublish1000Ms` 反而*变快*——"单指标上涨、其余下降"正是噪声的特征，第三次实测为 49.4 ms 并通过。因此在采信或处理失败前先复跑并观察离散度；若改动涉及热路径，就直接量化其开销（0.20.95 有界映射改写的微基准显示三种写法均为 80–86 ns/op，落在运行间波动之内）。基线迁移（例如某指标从空操作变为真实路径）属预期内的一次性失败。用 `pnpm bench:trend` 刷新长期趋势文档，表格变化时一并提交。**复跑失败可能亲手制造出让它通过的基线，这一点已被实测。** `bench:compare` 的基线（中位数与最大值两个条件）取自最近若干份归档报告，而每一次 `pnpm bench:browser` 都会往同一个归档里追加——于是排查失败时新增的样本，就变成了裁决下一次尝试的基线。2026-09-24：主机负载均值 7.7–15.1、待发布树的非注释 `src/` 差异为 0 行，前两次实测 `publish/dedicated 77.3 ms`、`publish/shared 67.7 ms`，相对约 38/34 ms 的快档在 50% 上限上失败；随后五次复跑报告 **OK**，因为基线中位数已经滑到 `70.6`。把这些样本移出归档后的一次干净实测显示所有指标同时上涨（`dedicated +92.5%`、`shared +99.2%`、`dedup +43.4%`、`trace +21.0%`），那是资源竞争的形态，与上文"单指标上涨、其余下降"的噪声形态相反。因此：复跑之前先看负载（`uptime`）；在满载主机上遇到可疑失败，就把数字连同负载一起记为"本轮推迟"，并将偏离常态的样本移出基线——也不要据它们重新生成 `docs/benchmarks.md`。
|
|
24
24
|
**这条既定决策在 0.21.17 被写下，那是处于该状态下的第五个发布周期：一个发布周期里始终没有安静的窗口时，就把这份采样连同当时的负载数字一起记为"本轮推迟"，而不是在满载主机上取它。** 推迟正是 `docs/benchmarks.md` 保持陈旧的原因，而"按机会更新"的这份陈旧是本步骤期望的结果，不是一道悄悄通过的门禁；真正不可接受的，是把一个受资源竞争的样本放进归档——那会变成下一次发布用来判定回归的基线。
|
|
25
25
|
5. 用 `npm pack --dry-run --json` 确认发布包只包含预期文件。
|
|
26
|
-
6. 在功能分支提交并推送该分支，PR 验证通过后使用 squash 或 fast-forward 合入（不创建 merge commit）。获取合入后的精确提交并打 tag，只推送该版本 tag；禁止直接推送 `main`/`master` 或 force-push。工作流运行 `node scripts/verify-release-version.mjs`，要求 `RELEASE_TAG` 等于 `v` 加 package 版本，且 CHANGELOG
|
|
26
|
+
6. 在功能分支提交并推送该分支，PR 验证通过后使用 squash 或 fast-forward 合入（不创建 merge commit）。获取合入后的精确提交并打 tag，只推送该版本 tag；禁止直接推送 `main`/`master` 或 force-push。工作流运行 `node scripts/verify-release-version.mjs`，要求 `RELEASE_TAG` 等于 `v` 加 package 版本，且 CHANGELOG 中恰好有一个非空的对应版本章节。同一步骤还会把 `CHANGELOG.md` 里每个版本标题与 registry 自己的 `time` 映射相对照，拒绝一份"点名了 npm 从未有过的版本"的发布记录——但只从 `0.20.85` 往上要求：在那之下有 40 个章节点名了 registry 从未记录过的版本，其中 27 个还带着 git tag（该计数取自 `v0.21.33` 发布当天；自己重算：`npm view cross-tab-worker-databus time --json`），这道门禁要拦的是新的漏洞，不是去翻历史旧账。而 registry 读取失败时，这一半会被跳过并打印一行警告、退出 0，而不是把一次好发布判红：为一个瞬时的 HTTP 失败拒绝一次成功发布，正是已发布消费者上限当初要避免的那类失败，所以只有*确认存在*的缺失才会中止发布。正在打 tag 的那个版本本身被豁免，因为它此刻本来就不该在 npm 上。
|
|
27
27
|
|
|
28
28
|
## 安全与依赖扫描
|
|
29
29
|
|
|
@@ -43,6 +43,6 @@
|
|
|
43
43
|
2. 在干净消费者中安装已发布版本或 tarball，并导入主入口及所有公开子路径。
|
|
44
44
|
3. 将结果记录到发布说明。在公开 API 和协议弃用策略明确冻结前，不进入 `1.0.0`。
|
|
45
45
|
|
|
46
|
-
打 tag 的发布工作流已自动执行上述消费者验证；仅在需要离线复验时才手动运行 `PUBLISHED_VERSION=<version> pnpm verify:published`。工作流的 12 分钟上限不是凑数，而是两段实测延迟之和。第一段：`npm publish` 返回成功后，registry 还要几分钟才把这条版本记进去——0.21.27 到 0.21.
|
|
46
|
+
打 tag 的发布工作流已自动执行上述消费者验证；仅在需要离线复验时才手动运行 `PUBLISHED_VERSION=<version> pnpm verify:published`。工作流的 12 分钟上限不是凑数，而是两段实测延迟之和。第一段：`npm publish` 返回成功后，registry 还要几分钟才把这条版本记进去——0.21.27 到 0.21.33 的"发布确认 → `time[<version>]`"间隔实测为 74.8–310.0 秒，按版本顺序分别是 248.7 / 96.8 / 74.8 / 310.0 / 127.2 / 76.1 / 75.5 秒（自己去 packument 读 `time[<version>]`，再和工作流 `Publish to npm` 步骤的完成时刻相减）。第二段：`npm pack` 用来解析版本的 packument 是以 `cache-control: public, max-age=300` 提供的，也就是说路径上任何一份副本按设计都可以旧五分钟，落在这一窗口内写入的版本，解析不太可能快过一整个缓存生命周期。究竟是哪个副本（npm 本地缓存，还是中间的 CDN）在下面提供了过期视图**并未确立**，而这段文字此前用作"反对纯本地解释"的那个观测，仔细读过之后站不住，因为它把两台机器拼成了一句话：21:44:34Z 那次"新鲜读取"是在笔记本上跑 `npm pack`，而 21:47:10Z 一秒就绿的是一次*全新的 runner 任务*，新任务的 npm 缓存本来是空的——这恰好是纯本地模型预测的结果，不是反驳它的结果。纯本地模型仍然解释不了的，只有一个读数：runner 自己在 21:45:07Z 仍然报 `ETARGET`——距离开始轮询的那一步（21:39:03Z）已经 364 秒，也就是比"那一刻抓到的副本必然已过期"的时间点（21:44:03Z，误差在请求真正发出的那一秒之内）还要晚约 60 秒。因此上限靠的是算术而不是模型：最坏情况的"确认 → `time[]`"间隔，加上一个缓存生命周期。这个和并非理论值——上一个 6 分钟上限被一次*成功*的发布排空过：0.21.30 的 tag 运行把整整 360 秒预算（48 × 7.5 秒）花在 `ETARGET` 上，而那时该版本的 tarball HEAD 和本地 `npm pack` 都已经成功；123 秒后同一步骤只用了 1 秒。0.20.89 针对它当时的 2 分钟预算也是同一形状。所以长时间的反复重试是正常的传播延迟，不是镜像异常慢——只有"确认 → `time[]`"间隔本身变长了，才需要继续调大 `PUBLISHED_VERIFY_ATTEMPTS` 和 `PUBLISHED_VERIFY_DELAY_MS`。手动复验时要注意这个不对称：`verify-published-consumer.mjs` 的默认值是 `6` 次 × `5_000` ms——30 秒而不是 12 分钟——因为更大的那一对是由 tag 工作流以 env 传入、而非脚本自带。于是手动复跑可能在一个 CI 全绿的版本上报出 `ETARGET`，这看起来像发布失败而实际不是；要对齐 CI 预算就显式执行 `PUBLISHED_VERSION=<version> PUBLISHED_VERIFY_ATTEMPTS=96 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`，否则请按你实际跑到的 30 秒预算来判断手动失败。把这个步骤的耗时当诊断读数而不是情绪指标：0.21.25 到 0.21.29 那五次*绿色* tag 运行分别用了 307、304、305、304、304 秒，0.21.31 用了 308 秒，0.21.32 和 0.21.33 各用了 304 秒——八个样本落在 5 秒的区间里，而这正是"一个 300 秒缓存生命周期 + 几秒命令时间"会预测出的形状（数字自己取：对每次发布运行 `gh api` 出来的 jobs 里，`Verify published npm consumers` 这一步的 `steps[].started_at`/`completed_at`）。0.21.31、0.21.32 与 0.21.33 是头三个跑在提高后的 720 秒上限下的发布，而它们三段延迟的切分方式不同，这个对照正是有用的地方：第一次是 127.2 秒落库 + 约 181 秒缓存；第二次是 76.1 秒落库 + 之后约 228 秒 runner 仍看不见它；第三次是 75.5 秒落库 + 约 229 秒——在 0.21.32 上，笔记本在 151 秒时用 `no-cache` 读 packument 已经能看到新的 `latest`，而 runner 自己的轮询一直到 304 秒才成功，也就是从*它自己*首次抓取算起整整一个生命周期。所以当初定这个上限的那个样本至今没有被超过：如果*确认 → `time[]`*这一段自己长过了 310 秒，就再调大 `PUBLISHED_VERIFY_ATTEMPTS`；而几秒就结束的 verify 只说明它读到的那份副本已经带上了新版本。
|
|
47
47
|
|
|
48
48
|
**不要用 `dist-tags.latest` 来判断发布是否发生。** 包文档端点与 tarball URL 是两条不同的读取路径，而它们的时间戳比这两条路径给的第一手印象更值得读。0.21.30 发布期间按顺序读到：`npm publish` 在 `21:39:03Z` 返回成功；`21:43:15Z` 的一次 `curl -s -H "Cache-Control: no-cache" https://registry.npmjs.org/<pkg>` 仍报 `latest` 是上一个版本、`versions` 里没有 `0.21.30`、`time['0.21.30']` 也不存在；而 npm 自己给这个版本盖的时间戳是 `21:44:12.987Z`，文档的 `last-modified` 是 `21:44:14 GMT`。所以 21:43:15 那次读取**不是**一份副本在拒绝已经存在的产物——registry 当时确实还没把这次发布记完，`no-cache` 也不可能让它看见尚不存在的版本；在发布步骤全绿之后的几分钟里，`versions` 与 `latest` 里没有这个版本，正是一次成功发布的正常状态。真正的读取路径分歧出现在 60 秒之后：`21:44:14Z` 到 `21:44:35Z` 之间，`curl -I …/-/<pkg>-0.21.30.tgz` 返回 `HTTP 200`，本地一次 `npm pack <pkg>@0.21.30 --registry https://registry.npmjs.org` 也成功写出了 tarball，而工作流 runner 自己的 `npm pack` 一直 `ETARGET` 到 `21:45:07Z` 把预算排空。同一个版本、两台机器、相隔一分钟给出相反答案。要回答"发布到底成没成"，去 HEAD 那个 tarball URL 并试一次 pack——它们摸到的是产物本身——而且要从**正在失败的那台机器**上去试，因为"能取到"是一台机器才有的答案；`latest` 只回答"消费者默认拿到哪个版本"，那是另一个问题，而且会更晚才稳定。`npm view <pkg> version` 在这之上还有第三条路径：它可能来自 npm 的**本地** packument 缓存，于是在发布前查过一次的机器上，即使全局 `latest` 已经前进，它仍会返回被取代的旧版本——这正是本门禁把目标版本固定取自 `PUBLISHED_VERSION`、并拒绝与 `package.json` 不一致的推断值的原因。不要因为一次元数据读取看起来过期就重推、移动或替换 tag；发布出去的 tag 是不可变的。
|
package/docs/zh/roadmap.md
CHANGED
|
@@ -1,6 +1,24 @@
|
|
|
1
1
|
# 路线图
|
|
2
2
|
|
|
3
|
-
0.21.
|
|
3
|
+
0.21.34 已于 2026 年 9 月 25 日发布。项目会先持续完成可靠性发布，再进入 1.0.0 稳定性冻结。
|
|
4
|
+
|
|
5
|
+
## 0.21.34 已完成范围
|
|
6
|
+
|
|
7
|
+
- **发布记录里点名了一个 npm 从未有过的版本时，打 tag 现在会被拒绝。** `scripts/verify-release-version.mjs` 在原有检查旁边读入 packument 的 `time` 映射，只要 `firstGatedRelease = 0.20.85` 及以上有某段 CHANGELOG 版本在 registry 里没有记录就失败。正在发布的那个版本按必要豁免，重复的小节只报一次，而读取 registry 失败时**告警并跳过**，不去把一次好发布判红——这是设计里刻意的那一半。下限来自计数而非口味：164 段里有 40 段点名了未发布的版本（`0.9.0`、`0.12.0` 到 `0.18.0` 每个 minor 的第一个 patch、`0.19.x` 全部十条、`0.20.0`–`0.20.5`、`0.20.54`、`0.20.55`、`0.20.69`、`0.20.72`–`0.20.84`；1 + 7 + 10 + 6 + 2 + 1 + 13 = 40）——把正在发布的那一条也算进去就是 41 段，而闸门豁免它正是这个原因——而它们全都在下限之下；从 `0.20.85` 一直到 `0.21.33` 的 47 条则一条不缺（这个数是本次 tag 自己的读数，每发布一次就加一，要取的是脚本打印的那一行）。四个变异体，四条具名测试，每次只红一条。
|
|
8
|
+
- **有一个淘汰跳过项没有任何测试能看见。** `rememberTopic()` 会跳过持有的 key *以及*本次正在记忆的 key；删掉后一项时 944 条测试全绿。它只在一种状态里可达：新写入的 `Map.set` 落在插入有序 Map 的**末尾**，所以只有更早的条目全部被持有时，从头扫描才会走到它——而在那里变异体丢掉的正是这次调用本要建立的映射。新用例摆出 500 条被收养的 peer SUBSCRIBE 帧加一条 PUBLISH，失败信息是 `expected [ 'owned.0', …(498) ] to include 'evict.extra'`；持有项仍由那条既有用例钉住，于是两个跳过各自有各自的击杀集。先前两种设计写不进去，原因记在用例注释里，因为它们看着合理却碰不到这条腿：入站 SUBSCRIBE 产生不出"未持有"的条目，而重复记忆一个已在表里的 key 撑不爆上限。
|
|
9
|
+
- **三句关于上限的既定文字，描述的是代码并不提供的保护。** `MAX_KNOWN_TOPICS = 500` 曾被写成"防止恶意 peer 借控制消息耗尽内存"；实测 1,200 条 peer `CONTROL/SUBSCRIBE` 让 `knownTopics` 和 `assignedTopics` 一起涨到 1,200——每个帧都会被收养，收养使它的 key 变为持有，而扫描随即拒绝删除任何东西；一轮 reconcile 把两者带回 `0`，所以洪水的界是清扫，上限的界只覆盖未持有的条目。`trace.ts` 把它的两个上限都说成在防"单个失控 topic"，而 `MAX_PENDING_TOPICS` 其实是对*不同* topic 的准入闸门（1,001 个 topic 得到 1,000 条队列，而一个已准入的 topic 仍会长到 256），`topics` 这张集合两个上限都不加，是刻意为之，由窗口刷新增界。同一份架构文档里的标识符表仍按修正前的说法复述淘汰规则，而它旁边那行漏掉了 `reconcileAssignedTopics`——唯一真正结束洪水的通路。两种语言全部改正，`src/` 的注释改为指向那个循环和那些测试，而不是把规则复述两遍。
|
|
10
|
+
- **与既有用例重复的候选测试应当删掉，而不是留下。** trace 的两个上限看起来没人钉，是因为检索用的是常量名，而那两条真正钉住它们的用例把数字写在注释里、通篇没提这两个标识符。两条新用例都写好了，随后变异检测报告：删掉准入守卫会红**两**条——新写的那条，以及输入规模更大的 `caps the number of topics tracked for pending receives`。于是新用例被删除，注释改为引用既有用例的名字。本次发布因此只新增一条测试（淘汰跳过项），不删除任何测试。
|
|
11
|
+
- **发布延迟样本扩到七段间隔、八个耗时，而上限的推导没动。** `0.21.33`：确认 `00:31:20Z`，registry 记录 `00:32:35.519Z`（**75.5 秒**），verify 步骤 **304 秒**——304–308 秒区间里的第八个绿色样本，也是从该 runner 自己首次抓取算起的一个 300 秒生命周期加命令时间。75.5 秒没有超过决定 720 秒预算的 310 秒，所以 `maxMeasuredAckToRecordMs` 原样保留，`tests/workflows.test.ts` 未作修改仍然通过。
|
|
12
|
+
- **没有变动的部分。** 库代码、导出、选项、默认值、帧格式与存储键均未改动；`verify:compat`、`verify:types`、`verify:pack` 针对 `v0.21.33` 运行，零计数分支账本与覆盖率聚合仍是 `0.21.33` 的。测试规模是 37 个文件 / 950 条。唯一新增的阻断行为在发布工作流自己的版本闸门里，而它在 registry 读取失败时自行跳过。
|
|
13
|
+
|
|
14
|
+
## 0.21.33 已完成范围
|
|
15
|
+
|
|
16
|
+
- **一条被当作"反证"的观测，其实把两台机器拼在了一起。** 关于发布延迟的正文曾用"重跑成功的时间早于 21:44 那次新鲜读取的 300 秒有效期到期"来反驳"纯 npm 本地缓存"的说法。对着运行记录看：那次新鲜读取是 21:44:35Z 笔记本上的 `npm pack`，而 1 秒就绿的那次是 21:47:10Z 的**全新 runner 任务**——新任务的缓存本来是空的，这正是本地模型预测的结果，不是反例。该论断撤回；本地模型仍然解释不了的，现在明确写成它本来的样子：只剩一个读数——runner 自己在 21:45:07Z 仍报 `ETARGET`，距轮询开启（21:39:03Z）已 364 秒，比那份副本理应过期的时刻还晚约 60 秒。结论依旧保持"未确立"。
|
|
17
|
+
- **写下这段的同时，`0.21.32` 送来了这个模型最干净的样本。** 发布确认 23:34:46Z，registry 记录 23:36:02.091Z（**76.1 秒**），笔记本在 151 秒时用 `no-cache` 已经读到新的 `latest`，而 runner 的阻塞步骤一直到 **304 秒** 才通过——从它自己首次抓取算起正好一个生命周期再加命令时间。于是 verify 耗时区间扩为七个绿色样本、304–308 秒；两份样本清单在两种语言、工作流注释、以及钉住下限的那条测试里都补齐了。
|
|
18
|
+
- **其中三个数字说的是另一个量，而且都在打 tag 之前改掉了。** "七个里第二小的"把耗时清单的个数借给了延迟清单——后者只有六个值（七个的那份是步骤*耗时*：307 / 304 / 305 / 304 / 304 / 308 / 304 秒），而且同一句话自己的括号里已经列了六个。另有三处写 0.21.30"把整整 **364 秒预算**花在 `ETARGET` 上"，可那一次的上限是 360 秒（48 × 7.5 秒），364 秒只是从它首次轮询到最后一个 `ETARGET` 的间隔——预算和读数被写成了同一个数。而 `docs/progress.md` 还留着那句的第一稿"比 21:44:05Z 本该失效的那次抓取晚大约 5 分 40 秒"，既不等于 364 秒的间隔，也不等于其它所有副本都写的"过期后再约 60 秒"。为了核对第一条，延迟清单声明区间之下的两个发布第一次被同样取样：0.21.25 是 **157.8 秒**（确认 17:56:53Z、记录 17:59:30.781Z），0.21.26 是 **96.1 秒**（确认 18:41:40Z、记录 18:43:16.084Z）——而它们的 verify 步骤耗时分别回到 307 秒和 304 秒，正是耗时清单里已有的那两个值，于是"哪次运行属于哪个版本"是被一个早就在案的数字确认的，不是靠新数字自证。现在共有八个延迟样本，没有一个超过 310.0 秒；这两个新读数写在这里和 `CHANGELOG.md`，而不是补进清单的每一处复述——多一份副本就多一处需要同步。
|
|
19
|
+
- **没有改的东西，以及证明它没改的检查。** 76.1 秒没有超过决定 720 秒上限的 310 秒，所以 `maxMeasuredAckToRecordMs` 原样不动，`tests/workflows.test.ts` 未作修改仍 6/6 通过——扩大样本而不必重算推导，正是这次发布想要的结果，而不是再调预算的理由。
|
|
20
|
+
- **历史记录按指针修正，而不是改写。** `CHANGELOG.md` 的 `0.21.31` 条目和两份 `docs/roadmap.md` 仍然保留当时写错的那句话，各自补上指明由 `0.21.33` 取代的说明，让记录读起来就是它本来的先后顺序。`AGENTS.md` 在"要从正在失败的那台机器去探"这条既有规则旁边，添了更一般的那条：把一次观测当作反证引用之前，先确认它的两半来自同一台机器、同一条读取路径。
|
|
21
|
+
- **没有动的东西。** 库代码、导出、配置项、默认值、帧格式与存储键都未变化；`verify:compat`、`verify:types`、`verify:pack` 针对 `v0.21.32` 运行，分支账本与覆盖率沿用 `0.21.32` 的（1951 支里 46 支零计数；99.02 / 97.64 / 99.27 / 99.69）。
|
|
4
22
|
|
|
5
23
|
## 0.21.32 已完成范围
|
|
6
24
|
|
|
@@ -12,7 +30,7 @@
|
|
|
12
30
|
|
|
13
31
|
## 0.21.31 已完成范围
|
|
14
32
|
|
|
15
|
-
- **那次"发布成功但闸门失败"的排查：预算改成测量出来的和，而不是凭感觉。** `0.21.30` 的 tag 运行把 48 × 7.5 秒的已发布消费者预算整个耗在 `ETARGET` 上，而针对同一个 tag 重跑时这一步只用了 1 秒。这个上限其实是两段延迟之和，两段现在都测过：`npm publish` 返回确认早于 registry 自己给这条版本盖的 `time[<version>]`——0.21.29 是 74.8 秒，0.21.28 是 96.8 秒，0.21.27 是 248.7 秒，0.21.30 是 310.0 秒；而 `npm pack` 用来解析的 packument 是以 `cache-control: public, max-age=300` 提供的，也就是说路径上任何一份副本按设计都可以旧一整个缓存生命周期。第二段也正是前三次绿色运行那可疑一致的 305 / 304 / 304 秒在报告的东西——一个在没人解释之前只会被读成噪声的规律。于是预算改为 96 × 7.5 秒 = 720 秒，覆盖 610 秒。究竟是哪一份副本提供了过期视图，这里是故意留空的：纯 npm 本地缓存的解释会预测重跑同样要等满 300
|
|
33
|
+
- **那次"发布成功但闸门失败"的排查：预算改成测量出来的和，而不是凭感觉。** `0.21.30` 的 tag 运行把 48 × 7.5 秒的已发布消费者预算整个耗在 `ETARGET` 上，而针对同一个 tag 重跑时这一步只用了 1 秒。这个上限其实是两段延迟之和，两段现在都测过：`npm publish` 返回确认早于 registry 自己给这条版本盖的 `time[<version>]`——0.21.29 是 74.8 秒，0.21.28 是 96.8 秒，0.21.27 是 248.7 秒，0.21.30 是 310.0 秒；而 `npm pack` 用来解析的 packument 是以 `cache-control: public, max-age=300` 提供的，也就是说路径上任何一份副本按设计都可以旧一整个缓存生命周期。第二段也正是前三次绿色运行那可疑一致的 305 / 304 / 304 秒在报告的东西——一个在没人解释之前只会被读成噪声的规律。于是预算改为 96 × 7.5 秒 = 720 秒，覆盖 610 秒。究竟是哪一份副本提供了过期视图，这里是故意留空的：纯 npm 本地缓存的解释会预测重跑同样要等满 300 秒，而它没有。（这一句已被 `0.21.33` 撤回：它把笔记本上的一次 `npm pack` 读取，和一个全新 runner 任务 1 秒就绿拼成了一句话，也就是两台机器；新任务的缓存本来是空的，"读到新鲜"正是纯本地模型预测的结果而不是反例。它真正解释不了的只剩一个读数——runner 在自己的副本理应过期约 60 秒之后仍然报 `ETARGET`——而 0.21.32 那次 304 秒的 verify 是这个模型最干净的一个样本，区间也因此扩到七个样本、304–308 秒。）
|
|
16
34
|
- **一道放过了"刚刚失败的那个值"的下限。** `tests/workflows.test.ts` 断言的是 `totalMs >= 5 * 60 * 1000`，也就是说把一次好发布判红的那个 360 秒预算，恰好满足这道专为阻止此事而存在的闸门，而且再往下调也不会有人拦。现在下限换成上面那两项之和，写成两个具名常量，并且把每一项怎么重新取数写在旁边。双向都做过核对：把工作流改回 48 会让这一条测试精确失败，报错信息同时点出两段延迟；同一条下限也会拒绝这里失败的 360 秒和 0.20.89 当年排空的 120 秒。
|
|
17
35
|
- **一条关于该失败的说明，被它自己的时间戳推翻。** 同一次发布期间写进发布清单的那段说，包文档端点与 tarball URL"在同一分钟里"给出了相反答案。而它自己引用的读数把那次过期文档读取放在 21:43:15Z，把 registry 对该版本的记录放在 21:44:12.987Z——所以那次读取根本不是在拒绝一个已经存在的产物，它是在如实报告一次 registry 还没写完的发布，`no-cache` 也救不了它。真正的分歧是：一台机器最迟在 21:44:35Z 已经能取到 tarball，而 runner 到 21:45:07Z 还在 `ETARGET`。因此正文现在要求**从正在失败的那台机器**去探，并且把"发布步骤全绿之后几分钟里 `versions`/`latest` 仍然没有它"写成一次成功发布的**预期**状态。
|
|
18
36
|
- **`wildcardPublishCache`：那条被文档化的上限并不覆盖的按 topic 映射，以及为什么加个上限不是免费的。** 它把具体 topic 映射到匹配它的本地通配模式，或映射到 `null` 表示"扫过，没匹配"；它没有任何界限，只在两处生命周期拆解里清理，位置与每一次 `routeOwnerCache.clear()` 相邻。实测：对互不相同的 topic 名调用 1,200 次 `publish()` 之后，`knownTopics` 仍停在 500 条上限，而这张表持有 1,200 条。逐出哪一半的代价并不对称——丢一个*模式*会重跑这张表本要阻止的首次本地分发；丢一个 `null` 会重新扫描，而如果这期间分派过一个通配，这次发布就会拿到只有首发才有的那种扇出。所以注释记下的是：要给这张表设界，需要的是一条"允许忘掉哪一半"的规则，不是一个数字。`docs/architecture.md` 在"上限与逐出"那段之后也写了同一件事。
|
|
@@ -557,6 +575,10 @@ DataBus 生命周期审计还固定了 initial `transport.start()` 被 `stop()`
|
|
|
557
575
|
|
|
558
576
|
- 在 cluster snapshot 与 diagnostics 中新增 peer 协议能力发现。当前 runtime 广播协议版本 1；旧 peer 显示为 `null`。
|
|
559
577
|
|
|
578
|
+
## 0.20.68 已完成范围
|
|
579
|
+
|
|
580
|
+
- 为集群帧和 worker snapshot 增加协议版本元数据，并保持旧版本缺失字段时的兼容处理。
|
|
581
|
+
|
|
560
582
|
## 0.20.67 已完成范围
|
|
561
583
|
|
|
562
584
|
- 新增未知协议消息计数与最近类型诊断，并纳入 `getDiagnostics()`，同时保持旧 runtime 安全忽略未知消息。
|
|
@@ -935,10 +957,6 @@ DataBus 生命周期审计还固定了 initial `transport.start()` 被 `stop()`
|
|
|
935
957
|
- 覆盖 WebSocket、Centrifuge、Worker 边界与浏览器 E2E 的 publication metadata 兼容性测试。
|
|
936
958
|
- Service Worker transport 决策：在目标浏览器具备稳定的连接生命周期契约前，刻意保持不实现。
|
|
937
959
|
|
|
938
|
-
## 0.20.68 已交付
|
|
939
|
-
|
|
940
|
-
- 为集群帧和 worker snapshot 增加协议版本元数据，并保持旧版本缺失字段时的兼容处理。
|
|
941
|
-
|
|
942
960
|
## 0.20.69 候选
|
|
943
961
|
|
|
944
962
|
1. ~~增加 peer 能力矩阵，并在 diagnostics 暴露 SDK、后端与 transport 身份。~~ 已交付：`getDiagnostics()` 携带协议版本、未知消息统计、peer 协议版本与 transport 身份；`getHealthSummary()`/`getMetrics()` 现在也会随单一对象输出实时 trace 指标与 sink 状态。
|
package/package.json
CHANGED