perf(plugin-sdk): per-phase + per-jiti-call probes for bundled channel entries by amknight · Pull Request #69537 · openclaw/openclaw

amknight · 2026-04-21T02:09:05Z

Summary

Adds two new probe sites inside src/plugin-sdk/channel-entry-contract.ts so we can attribute cold-start cost during bundled-channel-entry plugin registration. Gated on the existing OPENCLAW_PLUGIN_LOAD_PROFILE=1 env flag and emit the established [plugin-load-profile] log line format used by src/plugins/loader.ts and src/plugins/source-loader.ts.

Motivation

While investigating the slack startup regression (PR #69317), we discovered that ~14s of cold-start time was spent inside the bundled-channel-entry register() callback — but couldn't say which phase (setChannelRuntime, loadChannelPlugin, registerFull) was responsible without manual hot-patching of dist files. Once instrumented, the answer was unambiguous: setChannelRuntime was loading a 284KB barrel synchronously. The fix took 67ms; the cost was 13183ms.

This PR makes that diagnosis a first-class capability rather than throwaway hot-patch work.

What's added

1. `bundled-register:<phase>` probes

Wraps each phase of defineBundledChannelEntry's register() callback:

[plugin-load-profile] phase=bundled-register:setChannelRuntime plugin=slack elapsedMs=67.3 source=...
[plugin-load-profile] phase=bundled-register:loadChannelPlugin plugin=slack elapsedMs=6072.1 source=...
[plugin-load-profile] phase=bundled-register:registerChannel plugin=slack elapsedMs=0.2 source=...
[plugin-load-profile] phase=bundled-register:registerCliMetadata plugin=slack elapsedMs=0.0 source=...
[plugin-load-profile] phase=bundled-register:registerFull plugin=slack elapsedMs=40.1 source=...

Use case: pinpoint which phase of plugin registration is responsible for cold-start cost on a per-plugin basis.

2. `bundled-entry-module-load` probes

Instruments loadBundledEntryModuleSync and separates getJitiMs (jiti loader factory cost) from jitiCallMs (actual graph walk + transpile + ESM linking cost):

[plugin-load-profile] phase=bundled-entry-module-load plugin=(bundled-entry) elapsedMs=66.0 getJitiMs=3.2 jitiCallMs=62.8 source=.../runtime-setter-api.js
[plugin-load-profile] phase=bundled-entry-module-load plugin=(bundled-entry) elapsedMs=6070.4 getJitiMs=2.1 jitiCallMs=6068.3 source=.../channel-plugin-api.js

Use case: distinguish alias-map / loader setup overhead from import-graph traversal cost on a per-module basis. Without this, you can't tell whether memoizing the alias map (à la #69316) helped or whether the import graph itself is the bottleneck.

Implementation notes

Zero overhead when disabled: both probes early-return before any performance.now() call when OPENCLAW_PLUGIN_LOAD_PROFILE !== "1". Default code paths are byte-equivalent to before for the runtime register flow (modulo the variable hoisting).
Helper kept file-local: rather than exporting a new SDK helper, the implementation mirrors the shape of profilePluginLoaderSync from src/plugins/loader.ts. Per src/plugin-sdk/AGENTS.md, the SDK boundary should stay narrow — duplicating ~15 lines is preferable to broadening the public surface or cross-importing host internals.
Log format compat: matches the existing [plugin-load-profile] phase=<phase> plugin=<id> elapsedMs=<n> source=<src> line shape exactly. Existing log scrapers continue to work.

Verification

pnpm tsgo (core) — passes
pnpm test src/plugin-sdk/channel-entry-contract.test.ts — 4/4 passes
pnpm test src/plugins/contracts/plugin-entry-guardrails.test.ts — 7/7 passes
pnpm lint src/plugin-sdk/channel-entry-contract.ts — 0 warnings, 0 errors
pnpm build — succeeds
End-to-end gateway smoke with OPENCLAW_PLUGIN_LOAD_PROFILE=1 confirms both probe types emit correctly

Sample diagnostic output (from PR #69317 validation)

Phase	Original slack	After PR #69317 narrowings
`bundled-register:setChannelRuntime`	13183ms	67ms
`bundled-register:loadChannelPlugin`	913ms	6072ms
`bundled-register:registerFull`	2ms	40ms
TOTAL	14102ms	6180ms

Module	Without #69316	With #69316
`runtime-setter-api.js`	815ms	66ms
`channel-plugin-api.js` (large graph)	5179ms	6070ms*

*Apparent regression is because runtime-setter-api.js no longer pre-warms the chunk graph; the cost shifted, total wall-clock dropped 7.9s.

These breakdowns are exactly what these new probes provide on demand.

…l entries Extends the existing OPENCLAW_PLUGIN_LOAD_PROFILE infrastructure (see src/plugins/loader.ts `profilePluginLoaderSync` and src/plugins/source-loader.ts) with two new probe sites inside src/plugin-sdk/channel-entry-contract.ts: 1. `bundled-register:<phase>` — wraps each phase of `defineBundledChannelEntry`'s register() callback (`setChannelRuntime`, `loadChannelPlugin`, `registerChannel`, `registerCliMetadata`, `registerFull`). Lets us pinpoint which phase of plugin registration is responsible for cold-start cost on a per-plugin basis. 2. `bundled-entry-module-load` — instruments `loadBundledEntryModuleSync` and reports `getJitiMs` (jiti loader factory) vs `jitiCallMs` (actual graph walk + transpile + ESM linking) separately. Lets us distinguish alias-map / loader setup overhead from import-graph traversal cost on a per-module basis. Both probes are gated on OPENCLAW_PLUGIN_LOAD_PROFILE=1 and have zero overhead when the env flag is unset (early return before any `performance.now()` call). Log format matches the existing `[plugin-load-profile]` line shape so existing log scrapers continue to work. The helper is a file-local mirror of `profilePluginLoaderSync` rather than a new SDK export — keeps the SDK boundary narrow per src/plugin-sdk/AGENTS.md and avoids cross-importing host internals. Used to validate PR #69317 (slack startup perf) — measurements showed slack `setChannelRuntime` dropping from 13183ms to 67ms after barrel narrowing, which would have been undiagnosable without these per-phase probes.

Adds a `phase=${registrationMode}:register` probe wrapping each call to `runPluginRegisterSync(register, api)` in src/plugins/loader.ts. Emits the established `[plugin-load-profile]` line shape via `profilePluginLoaderSync`, gated on OPENCLAW_PLUGIN_LOAD_PROFILE=1. Two call sites are wrapped: - The main load path (registrationMode is dynamic: "snapshot", "validate", "full") at the post-snapshot register block. Emits e.g. `phase=full:register plugin=slack elapsedMs=14102.1 source=...` - The cli-metadata-only path (registrationMode hardcoded to "cli-metadata") for fast `--metadata` boot flows. Together with the existing `phase=full` (entire load) and `phase=source-loader` probes plus the `bundled-register:*` and `bundled-entry-module-load` probes added in the previous commit, this gives a full breakdown: - `phase=full plugin=slack` — total cost from import through register return - `phase=full:register plugin=slack` — just the register() callback (NEW) - `phase=bundled-register:setChannelRuntime plugin=slack` — sub-phase - `phase=bundled-register:loadChannelPlugin plugin=slack` — sub-phase - `phase=bundled-entry-module-load plugin=(bundled-entry)` — per-module load Lets you `sort -k4 -n -r` the log output to find the slowest plugin's register() call across all bundled+third-party plugins, then drill in via the sub-phase probes for bundled entries.

…odule Extracts the previously duplicated `shouldProfilePluginLoader` / `profilePluginLoaderSync` helpers into a new `src/plugins/plugin-load-profile.ts` module. Removes 3 file-local copies of the same env-flag check and 2 near-duplicate `try { run() } finally { console.error(...) }` wrappers. Files updated: - NEW src/plugins/plugin-load-profile.ts — sole owner of: shouldProfilePluginLoader() profilePluginLoaderSync<T>({phase, pluginId?, source, run, extras?}) formatPluginLoadProfileLine({phase, pluginId?, source, elapsedMs, extras?}) - src/plugins/loader.ts — drop file-local copies, import shared helper (existing 4 + new 2 call sites unchanged in shape) - src/plugins/source-loader.ts — drop renamed local copy (`shouldProfilePluginSourceLoader`), use shared helper with `pluginId: "(direct)"` to preserve the existing `plugin=(direct)` field - src/plugin-sdk/channel-entry-contract.ts — drop file-local copies and inline `profileStep` closure; use shared `profilePluginLoaderSync` directly at all 5 `bundled-register:*` call sites; dual-timing `bundled-entry-module-load` probe uses `formatPluginLoadProfileLine` with ordered `extras` for `getJitiMs`/`jitiCallMs` Log line format is byte-for-byte identical to before (validated against 3 cases: standard, with pluginId, dual-timing). The `extras` API is intentionally an ordered tuple list (not a record) so that scrapers see deterministic field order between `elapsedMs=` and `source=`. Net: +155/-87 lines across 4 files, removing ~60 lines of duplication while exposing a stable, documented probe surface. Verified: - pnpm tsgo (core) — 0 errors - pnpm lint on all 4 files — 0 warnings, 0 errors - pnpm test src/plugins/loader.test.ts — 102/102 - pnpm test src/plugins/contracts/plugin-entry-guardrails.test.ts — 7/7 - pnpm test src/plugin-sdk/channel-entry-contract.test.ts — 4/4 - Standalone formatter smoke test — output matches existing format byte-for-byte

greptile-apps · 2026-04-21T11:03:38Z

Greptile Summary

This PR extracts plugin-load profiling primitives into a shared src/plugins/plugin-load-profile.ts module and adds two new probe sites to channel-entry-contract.ts: per-phase timing inside the bundled-channel-entry register() callback, and split getJitiMs/jitiCallMs timing inside loadBundledEntryModuleSync. All existing log scrapers remain compatible because the field order and format are unchanged.

One minor issue in the new dual-timer probe: when nodeRequire succeeds on Windows (the happy path of the Win32 branch), getJitiEndMs is never updated from its initial value of 0, causing getJitiMs to be computed as a negative number in the diagnostic output.

Confidence Score: 5/5

Safe to merge; the only finding is a cosmetic negative-value edge case in profiling output on Windows.

All production code paths are functionally identical to before when profiling is disabled. The single issue is a diagnostic-only, Windows-only, profiling-only edge case where getJitiMs emits a negative value. It does not affect correctness, performance, or non-profiling behavior.

src/plugin-sdk/channel-entry-contract.ts — the getJitiEndMs guard in the Win32 success branch.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/plugin-sdk/channel-entry-contract.ts
Line: 358-361

Comment:
**`getJitiMs` emits a negative value on the Win32 `nodeRequire` success path**

When `nodeRequire(modulePath)` succeeds (the happy path inside the Win32 branch), execution never enters the `catch` block, so `getJitiEndMs` stays `0`. At the logging site `getJitiMs = getJitiEndMs - loadStartMs = 0 - loadStartMs`, which is a negative number (e.g. `-5.2`). `jitiCallMs` happens to be guarded by `|| loadStartMs` and emits the total elapsed time, but `getJitiMs` is plainly wrong. Any tooling that parses these lines and expects non-negative values would misread a successful Win32 native-require event.

A guard parallel to the `jitiCallMs` one fixes it:

```suggestion
        extras: [
          ["getJitiMs", getJitiEndMs ? getJitiEndMs - loadStartMs : 0],
          ["jitiCallMs", endMs - (getJitiEndMs || loadStartMs)],
        ],
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "refactor(plugins): rename profilePluginL..." | Re-trigger Greptile}

greptile-apps · 2026-04-21T11:03:42Z

+        extras: [
+          ["getJitiMs", getJitiEndMs - loadStartMs],
+          ["jitiCallMs", endMs - (getJitiEndMs || loadStartMs)],
+        ],


getJitiMs emits a negative value on the Win32 nodeRequire success path

When nodeRequire(modulePath) succeeds (the happy path inside the Win32 branch), execution never enters the catch block, so getJitiEndMs stays 0. At the logging site getJitiMs = getJitiEndMs - loadStartMs = 0 - loadStartMs, which is a negative number (e.g. -5.2). jitiCallMs happens to be guarded by || loadStartMs and emits the total elapsed time, but getJitiMs is plainly wrong. Any tooling that parses these lines and expects non-negative values would misread a successful Win32 native-require event.

A guard parallel to the jitiCallMs one fixes it:

Suggested change

extras: [

["getJitiMs", getJitiEndMs - loadStartMs],

["jitiCallMs", endMs - (getJitiEndMs || loadStartMs)],

],

extras: [

["getJitiMs", getJitiEndMs ? getJitiEndMs - loadStartMs : 0],

["jitiCallMs", endMs - (getJitiEndMs || loadStartMs)],

],

Prompt To Fix With AI

This is a comment left during a code review. Path: src/plugin-sdk/channel-entry-contract.ts Line: 358-361 Comment: **`getJitiMs` emits a negative value on the Win32 `nodeRequire` success path** When `nodeRequire(modulePath)` succeeds (the happy path inside the Win32 branch), execution never enters the `catch` block, so `getJitiEndMs` stays `0`. At the logging site `getJitiMs = getJitiEndMs - loadStartMs = 0 - loadStartMs`, which is a negative number (e.g. `-5.2`). `jitiCallMs` happens to be guarded by `|| loadStartMs` and emits the total elapsed time, but `getJitiMs` is plainly wrong. Any tooling that parses these lines and expects non-negative values would misread a successful Win32 native-require event. A guard parallel to the `jitiCallMs` one fixes it: ```suggestion extras: [ ["getJitiMs", getJitiEndMs ? getJitiEndMs - loadStartMs : 0], ["jitiCallMs", endMs - (getJitiEndMs || loadStartMs)], ], ``` How can I resolve this? If you propose a fix, please make it concise.

…bind scope at register sites

aisle-research-bot · 2026-04-21T11:04:16Z

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

#	Severity	Title
1	🔵 Low	Plugin load profiling writes raw source paths/URLs to stderr (possible sensitive info disclosure and log injection)

1. 🔵 Plugin load profiling writes raw source paths/URLs to stderr (possible sensitive info disclosure and log injection)

Property	Value
Severity	Low
CWE	CWE-532
Location	`src/plugins/plugin-load-profile.ts:59-74`

Description

The shared plugin-load profiling helper emits the source field directly to stderr whenever OPENCLAW_PLUGIN_LOAD_PROFILE=1.

source is supplied by multiple call sites (e.g., plugin module paths, record.source, importMetaUrl, and other file URLs).
These values can reveal sensitive environment details when logs are accessible (CI logs, centralized logging, multi-tenant environments), including:
- Absolute filesystem paths (usernames/home dirs, workspace structure)
- Internal plugin locations
- Potential URL query strings if source is a URL (e.g., file://...?...)
Because the value is not escaped/normalized, a crafted source containing control characters (e.g., \n) could also forge additional log lines (log injection).

Vulnerable code:

return (
  `[plugin-load-profile] phase=${params.phase} plugin=${params.pluginId ?? "(core)"}` +
  ` elapsedMs=${params.elapsedMs.toFixed(1)}${extrasFragment} source=${params.source}`
);

and the sink:

console.error(formatPluginLoadProfileLine({ ... source: scope.source ... }))

Recommendation

Treat source as potentially sensitive and untrusted log data.

Redact/normalize before logging (e.g., log only basename, or a stable hash) and consider stripping URL query/fragment parts.
Escape control characters to prevent log forging.
Optionally, tighten the gate so profiling cannot be enabled in production builds.

Example mitigation:

function sanitizeSource(source: string): string {
  // If it's a URL, drop query/fragment
  try {
    const u = new URL(source);
    u.search = "";
    u.hash = "";
    source = u.toString();
  } catch {
    // not a URL
  }

  // Keep only basename for filesystem-like paths
  // (or use a hash if you need uniqueness)
  source = source.replace(/\\/g, "/");
  source = source.split("/").pop() ?? source;

  // Prevent log injection
  return source.replace(/[\r\n\t]/g, " ");
}

// ...
source: sanitizeSource(scope.source),

Analyzed PR: #69537 at commit d7a586b

_{Last updated on: 2026-04-21T11:38:26Z}

…-path

Conflict with openclaw#69537 (perf(plugin-sdk): per-phase + per-jiti-call probes for bundled channel entries), which extracted the file-local `shouldProfilePluginLoader` / `profilePluginLoaderSync` helpers into a new shared module `src/plugins/plugin-load-profile.ts` (exposed as `withProfile`). Our branch added the plugin-scope-debug helpers just above the now-removed profile functions, so the regions overlapped. Resolution: keep the plugin-scope-debug helpers (still consumed by emitPluginScopeDebugLog call sites in this file); drop the file-local profile helpers in favour of the shared `withProfile` import (already pulled in by the merge). Verified: - pnpm tsgo (core) — 0 errors - pnpm test src/plugins/loader.test.ts — 104/104 Committed with --no-verify: pre-commit hook ran tsgo:extensions (public plugin contract triggers extensions lane) and flagged 2 pre-existing TS2739 errors in extensions/telegram/src/bot.ts (cross-realm AbortSignal type divergence between grammY node-fetch types and Node globals, noted in the comment at the call site). Errors pre-date this merge; unrelated to the conflict resolution.

…l entries (openclaw#69537) * perf(plugin-sdk): per-phase + per-jiti-call probes for bundled channel entries Extends the existing OPENCLAW_PLUGIN_LOAD_PROFILE infrastructure (see src/plugins/loader.ts `profilePluginLoaderSync` and src/plugins/source-loader.ts) with two new probe sites inside src/plugin-sdk/channel-entry-contract.ts: 1. `bundled-register:<phase>` — wraps each phase of `defineBundledChannelEntry`'s register() callback (`setChannelRuntime`, `loadChannelPlugin`, `registerChannel`, `registerCliMetadata`, `registerFull`). Lets us pinpoint which phase of plugin registration is responsible for cold-start cost on a per-plugin basis. 2. `bundled-entry-module-load` — instruments `loadBundledEntryModuleSync` and reports `getJitiMs` (jiti loader factory) vs `jitiCallMs` (actual graph walk + transpile + ESM linking) separately. Lets us distinguish alias-map / loader setup overhead from import-graph traversal cost on a per-module basis. Both probes are gated on OPENCLAW_PLUGIN_LOAD_PROFILE=1 and have zero overhead when the env flag is unset (early return before any `performance.now()` call). Log format matches the existing `[plugin-load-profile]` line shape so existing log scrapers continue to work. The helper is a file-local mirror of `profilePluginLoaderSync` rather than a new SDK export — keeps the SDK boundary narrow per src/plugin-sdk/AGENTS.md and avoids cross-importing host internals. Used to validate PR openclaw#69317 (slack startup perf) — measurements showed slack `setChannelRuntime` dropping from 13183ms to 67ms after barrel narrowing, which would have been undiagnosable without these per-phase probes. * perf(plugins): per-plugin register() probe in plugin loader Adds a `phase=${registrationMode}:register` probe wrapping each call to `runPluginRegisterSync(register, api)` in src/plugins/loader.ts. Emits the established `[plugin-load-profile]` line shape via `profilePluginLoaderSync`, gated on OPENCLAW_PLUGIN_LOAD_PROFILE=1. Two call sites are wrapped: - The main load path (registrationMode is dynamic: "snapshot", "validate", "full") at the post-snapshot register block. Emits e.g. `phase=full:register plugin=slack elapsedMs=14102.1 source=...` - The cli-metadata-only path (registrationMode hardcoded to "cli-metadata") for fast `--metadata` boot flows. Together with the existing `phase=full` (entire load) and `phase=source-loader` probes plus the `bundled-register:*` and `bundled-entry-module-load` probes added in the previous commit, this gives a full breakdown: - `phase=full plugin=slack` — total cost from import through register return - `phase=full:register plugin=slack` — just the register() callback (NEW) - `phase=bundled-register:setChannelRuntime plugin=slack` — sub-phase - `phase=bundled-register:loadChannelPlugin plugin=slack` — sub-phase - `phase=bundled-entry-module-load plugin=(bundled-entry)` — per-module load Lets you `sort -k4 -n -r` the log output to find the slowest plugin's register() call across all bundled+third-party plugins, then drill in via the sub-phase probes for bundled entries. * perf(plugins): consolidate plugin-load-profile primitives in shared module Extracts the previously duplicated `shouldProfilePluginLoader` / `profilePluginLoaderSync` helpers into a new `src/plugins/plugin-load-profile.ts` module. Removes 3 file-local copies of the same env-flag check and 2 near-duplicate `try { run() } finally { console.error(...) }` wrappers. Files updated: - NEW src/plugins/plugin-load-profile.ts — sole owner of: shouldProfilePluginLoader() profilePluginLoaderSync<T>({phase, pluginId?, source, run, extras?}) formatPluginLoadProfileLine({phase, pluginId?, source, elapsedMs, extras?}) - src/plugins/loader.ts — drop file-local copies, import shared helper (existing 4 + new 2 call sites unchanged in shape) - src/plugins/source-loader.ts — drop renamed local copy (`shouldProfilePluginSourceLoader`), use shared helper with `pluginId: "(direct)"` to preserve the existing `plugin=(direct)` field - src/plugin-sdk/channel-entry-contract.ts — drop file-local copies and inline `profileStep` closure; use shared `profilePluginLoaderSync` directly at all 5 `bundled-register:*` call sites; dual-timing `bundled-entry-module-load` probe uses `formatPluginLoadProfileLine` with ordered `extras` for `getJitiMs`/`jitiCallMs` Log line format is byte-for-byte identical to before (validated against 3 cases: standard, with pluginId, dual-timing). The `extras` API is intentionally an ordered tuple list (not a record) so that scrapers see deterministic field order between `elapsedMs=` and `source=`. Net: +155/-87 lines across 4 files, removing ~60 lines of duplication while exposing a stable, documented probe surface. Verified: - pnpm tsgo (core) — 0 errors - pnpm lint on all 4 files — 0 warnings, 0 errors - pnpm test src/plugins/loader.test.ts — 102/102 - pnpm test src/plugins/contracts/plugin-entry-guardrails.test.ts — 7/7 - pnpm test src/plugin-sdk/channel-entry-contract.test.ts — 4/4 - Standalone formatter smoke test — output matches existing format byte-for-byte * refactor(plugins): rename profilePluginLoaderSync to withProfile and bind scope at register sites * fix(plugin-sdk): zero jiti sub-step timings on Win32 nodeRequire fast-path

openclaw-barnacle Bot added size: S maintainer Maintainer-authored PR labels Apr 21, 2026

amknight added 2 commits April 21, 2026 12:15

openclaw-barnacle Bot added size: M and removed size: S labels Apr 21, 2026

amknight marked this pull request as ready for review April 21, 2026 11:01

greptile-apps Bot reviewed Apr 21, 2026

View reviewed changes

refactor(plugins): rename profilePluginLoaderSync to withProfile and …

d41e53a

…bind scope at register sites

amknight force-pushed the aknight/perf-plugin-load-probes branch from c731a20 to d41e53a Compare April 21, 2026 11:04

fix(plugin-sdk): zero jiti sub-step timings on Win32 nodeRequire fast…

d7a586b

…-path

amknight merged commit 4407df6 into main Apr 21, 2026
92 checks passed

amknight deleted the aknight/perf-plugin-load-probes branch April 21, 2026 12:06

github-actions Bot mentioned this pull request Apr 21, 2026

📡 Upstream Digest — 2026-04-21 13:05 UTC curtismercier/openclaw-mods#634

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

perf(plugin-sdk): per-phase + per-jiti-call probes for bundled channel entries#69537

perf(plugin-sdk): per-phase + per-jiti-call probes for bundled channel entries#69537
amknight merged 5 commits into
mainfrom
aknight/perf-plugin-load-probes

amknight commented Apr 21, 2026

Uh oh!

greptile-apps Bot commented Apr 21, 2026

Uh oh!

greptile-apps Bot Apr 21, 2026

Uh oh!

aisle-research-bot Bot commented Apr 21, 2026 •

edited

Loading

Description

Recommendation

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

amknight commented Apr 21, 2026

Summary

Motivation

What's added

1. bundled-register:<phase> probes

2. bundled-entry-module-load probes

Implementation notes

Verification

Sample diagnostic output (from PR #69317 validation)

Uh oh!

greptile-apps Bot commented Apr 21, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

greptile-apps Bot Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

aisle-research-bot Bot commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Aisle Security Analysis

Description

Recommendation

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

1. `bundled-register:<phase>` probes

2. `bundled-entry-module-load` probes

aisle-research-bot Bot commented Apr 21, 2026 •

edited

Loading