docs: note upstream PRs #86797/#86850 share the same WeakMap strategy, narrower scope

Both PRs use WeakMap<index-object, fingerprint> to memoize
`resolveInstalledManifestRegistryIndexFingerprint`. Different layer
than this plugin's fs-level TTL — theirs only fires when the same
InstalledPluginIndex instance is passed twice; ours fires for every
stat/realpath on a plugin-tree path regardless of caller.

discoverInDirectory walks, the realpathSync ancestor-lstat chain, and
the loadConfig()-via-pushMetaToMonitor path don't go through the
fingerprint function, so this plugin keeps catching that traffic even
once their PR lands. Reevaluate the need then.

Both upstream PRs are blocked on review (type-check failure + need for
real-behavior profile evidence). Our prod 92-98% hit-ratio + 25%→<1%
baseline is exactly the evidence shape they're asking for, but
upstream involvement is intentionally out of scope per project decision.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
h z
2026-05-27 10:37:11 +01:00
parent 49bcde41ec
commit dfb581f5f0

View File

@@ -28,7 +28,7 @@ turning what should be a cheap snapshot hit into a sustained CPU drain.
Same hot path is observed in these upstream tickets: Same hot path is observed in these upstream tickets:
- [#86791 — repeated lstat/realpathSync in InstalledPluginIndex fingerprinting (memoization missing)](https://github.com/openclaw/openclaw/issues/86791) — **open, P2**, exact same call chain (`lstat and realpathSync under resolvePackageJsonPath -> buildInstalledManifestRegistryIndexKey -> resolveInstalledManifestRegistryIndexFingerprint`); two linked PRs (#86797, #86850) in progress. Once that lands, this plugin becomes unnecessary. - [#86791 — repeated lstat/realpathSync in InstalledPluginIndex fingerprinting (memoization missing)](https://github.com/openclaw/openclaw/issues/86791) — **open, P2**, exact same call chain (`lstat and realpathSync under resolvePackageJsonPath -> buildInstalledManifestRegistryIndexKey -> resolveInstalledManifestRegistryIndexFingerprint`). Two linked PRs (#86797, #86850) both try the same WeakMap-keyed-by-index-object memo strategy; both are blocked on review (type-check + real-behavior-proof). They only cover `resolveInstalledManifestRegistryIndexFingerprint` — they don't help with `discoverInDirectory` walks or with `realpathSync`'s ancestor-`lstat` chain. Even after they merge, this plugin's fs-layer TTL still catches stat traffic the WeakMap doesn't see; reevaluate then.
- [#67040 — persist plugin discovery cache + defer plugin loading](https://github.com/openclaw/openclaw/issues/67040) (closed as *not planned*) - [#67040 — persist plugin discovery cache + defer plugin loading](https://github.com/openclaw/openclaw/issues/67040) (closed as *not planned*)
- [#75297 — gateway event-loop saturation, very slow sessions.list after 2026.4.23](https://github.com/openclaw/openclaw/issues/75297) (workaround: rollback to 2026.4.23) - [#75297 — gateway event-loop saturation, very slow sessions.list after 2026.4.23](https://github.com/openclaw/openclaw/issues/75297) (workaround: rollback to 2026.4.23)
- [#28587 — plugin runtime eagerly loads channel SDKs causing sustained high CPU on startup](https://github.com/openclaw/openclaw/issues/28587) (closed by PR #28620, but only fixed the startup path, not the per-turn cost) - [#28587 — plugin runtime eagerly loads channel SDKs causing sustained high CPU on startup](https://github.com/openclaw/openclaw/issues/28587) (closed by PR #28620, but only fixed the startup path, not the per-turn cost)