perf(memory): prewarm explicit local embeddings on gateway startup by taosiyuan163 · Pull Request #70596 · openclaw/openclaw

taosiyuan163 · 2026-04-23T12:15:32Z

Summary

Problem: builtin memory_search with explicit memorySearch.provider = "local" still pays model/context initialization on the first post-startup search because gateway startup only warmed QMD.
Why it matters: the first memory-backed reply after a gateway restart absorbs the local embedding cold start instead of the post-attach startup path.
What changed: extend startGatewayMemoryBackend to prewarm builtin local managers by calling probeEmbeddingAvailability() after manager creation, and add gateway startup tests for explicit-local, skip, and failure logging paths.
What did NOT change (scope boundary): this does not prewarm provider = "auto" or remote embedding providers, so startup avoids new remote network calls or auth/cost side effects.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related [Performance] memory_search cold start ~5-7s — needs module pre-warming #70460
This PR fixes a bug or regression

Real behavior proof (required for external PRs)

Behavior or issue addressed: builtin memory with explicit memorySearch.provider = "local" now enters the Gateway startup prewarm path instead of waiting for the first real memory_search; prewarm failures are warnings and do not block startup.
Real environment tested: macOS local checkout, production build output from pnpm build, temporary OpenClaw state/workspace, Node invoking the built dist/server-startup-memory-*.js module.
Exact steps or command run after this patch: ran the built startup module with a temporary config using memory.backend=builtin, agents.defaults.memorySearch.provider=local, vector disabled, and a temporary memory/MEMORY.md file.
Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

proof module: server-startup-memory-DNxA_AEE.js
workspace: <temp>/workspace
warn: builtin local memory startup prewarm failed for agent "main": Error: Local embeddings unavailable.
Reason: optional dependency node-llama-cpp is missing (or failed to install).
Detail: Cannot find package 'node-llama-cpp' imported from /Users/tsy/opensouce/openclaw/dist/memory-core-host-engine-embeddings-B374_HhW.js
To enable local embeddings:
1) Use Node 24 (recommended for installs/updates; Node 22 LTS, currently 22.16+, remains supported)
2) Install node-llama-cpp next to the OpenClaw package or source checkout
3) If you use pnpm: pnpm approve-builds (select node-llama-cpp), then pnpm rebuild node-llama-cpp
Or set agents.defaults.memorySearch.provider = "github-copilot" (remote).
Or set agents.defaults.memorySearch.provider = "openai" (remote).
Or set agents.defaults.memorySearch.provider = "gemini" (remote).
Or set agents.defaults.memorySearch.provider = "voyage" (remote).
Or set agents.defaults.memorySearch.provider = "mistral" (remote).
Or set agents.defaults.memorySearch.provider = "deepinfra" (remote).
Or set agents.defaults.memorySearch.provider = "bedrock" (remote).
result: startup hook completed with 1 log event(s)

Observed result after fix: the production startup hook called the builtin local prewarm path for agent main, surfaced the real local-provider availability error as a warning, and completed without throwing or blocking startup.
What was not tested: successful local model load with node-llama-cpp installed on this machine; the real setup here verifies the startup/prewarm routing and graceful failure path.
Before evidence (optional but encouraged): before this patch, builtin backends were skipped by startGatewayMemoryBackend unless the resolved backend was QMD, so this same builtin/local startup path did not call the memory manager prewarm probe.

Root Cause (if applicable)

Root cause: post-attach startup only initialized QMD memory, so builtin local memory waited until the first real search to create the manager and load the local embedding context.
Missing detection / guardrail: gateway startup coverage did not assert builtin explicit-local prewarm behavior or failure logging.
Contributing context (if known): purpose: "status" managers bypass the builtin cache, so a status-only probe would not have helped the first real search.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/gateway/server-startup-memory.test.ts
Scenario the test should lock in: explicit local builtin memory runs probeEmbeddingAvailability() at startup, non-local builtin configs skip startup work, and probe failures degrade to warnings.
Why this is the smallest reliable guardrail: it exercises the gateway startup decision point without requiring real local model assets.
Existing test that already covers this (if any): existing QMD startup tests in the same file.
If no new test is added, why not: N/A

User-visible / Behavior Changes

Gateways using builtin memory with agents.*.memorySearch.provider = "local" now shift local embedding cold-start work into post-attach startup, so the first real memory_search request avoids paying that initialization cost.
No behavior change for QMD, provider = "auto", or remote memory embedding providers.

Diagram (if applicable)

Before:
gateway boot -> first builtin local memory_search -> init local embedding context -> delayed first result

After:
gateway boot -> post-attach startup prewarm -> first builtin local memory_search -> reuse warmed context

Security Impact (required)

New permissions/capabilities? (Yes/No) No
Secrets/tokens handling changed? (Yes/No) No
New/changed network calls? (Yes/No) No
Command/tool execution surface changed? (Yes/No) No
Data access scope changed? (Yes/No) No
If any Yes, explain risk + mitigation:

Repro + Verification

Environment

OS: macOS
Runtime/container: Node.js via pnpm
Model/provider: builtin memory with explicit local embedding provider
Integration/channel (if any): N/A
Relevant config (redacted): memory.backend=builtin, agents.defaults.memorySearch.provider=local

Steps

Start the gateway with builtin memory and an explicit local memory provider.
Let post-attach startup run.
Trigger the first memory_search request after startup.

Expected

The first real search reuses a manager whose local embedding provider has already been prewarmed.
Non-local builtin configs still skip startup warmup.
Failed prewarm attempts only log warnings.

Actual

Before this change, only QMD was warmed at startup, so builtin local memory paid the cold-start cost on the first real search.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios: pnpm test src/gateway/server-startup-memory.test.ts; pnpm build
Edge cases checked: builtin non-local skip path, builtin local probe failure logging, existing QMD startup path
What you did not verify: end-to-end timing against a real local model cache/download on a fresh gateway boot

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes/No) Yes
Config/env changes? (Yes/No) No
Migration needed? (Yes/No) No
If yes, exact upgrade steps:

Risks and Mitigations

Risk: explicit local memory configs now do extra startup work and could log a warning earlier in the boot cycle.
Mitigation: the prewarm runs only for memory.backend=builtin plus explicit provider=local, after post-attach startup, and failures degrade to warnings without blocking startup.

greptile-apps · 2026-04-23T12:17:20Z

Greptile Summary

This PR extends startGatewayMemoryBackend to prewarm builtin memory managers with an explicit provider = "local" setting at gateway startup, shifting local embedding cold-start cost out of the first real memory_search request. The change is narrowly scoped to backend = "builtin" + explicit provider = "local", leaving auto and remote providers untouched, and probe failures degrade gracefully to warnings.

Confidence Score: 5/5

Safe to merge — change is narrowly scoped, error paths are guarded, and new tests cover the key decision branches.

All remaining observations are P2 or lower. The implementation logic is correct, error handling is complete (try/catch wrapping the async probe plus probe.ok check), and the startup path is non-blocking for all non-local configurations.

No files require special attention.

_{Reviews (1): Last reviewed commit: "perf(memory): prewarm builtin local embe..." | Re-trigger Greptile}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9d47f64291

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-04-23T12:20:18Z

+    }
+
+    try {
+      const probe = await manager.probeEmbeddingAvailability();


Avoid caching failed builtin prewarm initialization

Calling probeEmbeddingAvailability() here runs against the default (cached) builtin manager, so a transient provider-init failure during startup can permanently break memory search for that process. MemoryIndexManager.get(...) reuses the same default manager instance, and ensureProviderInitialized() keeps a rejected init promise on failure (it only clears after successful initialization), so once prewarm fails early (for example while local model assets are still unavailable), subsequent memory_search calls keep reusing a poisoned manager instead of retrying later when the provider is ready.

Useful? React with 👍 / 👎.

taosiyuan163 · 2026-04-24T11:25:58Z

Pushed follow-up commit f325ad4 to relax the Codex missing-auth contract assertion so equivalent openai/gpt-5.5 and openai-codex/gpt-5.5 guidance both satisfy the shared test helper.

Local verification:

pnpm test src/plugins/provider-runtime.test.ts
pnpm test extensions/openai/provider-catalog.contract.test.ts
pnpm test extensions/openai
OPENCLAW_EXTENSION_BATCH_PARALLEL=1 OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test:extensions:batch -- "acpx,alibaba,anthropic,arcee,firecrawl,minimax,openai,qianfan,qwen,tavily,telegram,tlon,tokenjuice,vllm,zalouser" (completed green through the shard-2 coverage set; the local tool timed out right after the final tiny lane, which I reran separately with pnpm test extensions/tokenjuice and pnpm test extensions/vllm)

The new PR head currently only has the pull_request_target labeler suite attached. If pull_request CI is awaiting approval / rerun for the updated fork head, please re-enable or rerun the CI workflow on this latest commit.

clawsweeper · 2026-04-29T04:27:53Z

Codex review: needs real behavior proof before merge. Reviewed June 9, 2026, 1:08 AM ET / 05:08 UTC.

Summary
The branch adds Gateway post-attach and memory-startup handling for builtin memorySearch.provider = "local", adjusts MemoryIndexManager provider-init retry coverage, changes a Codex provider test helper, and adds a changelog entry.

PR surface: Source +79, Tests +134, Docs +1. Total +214 across 8 files.

Reproducibility: Partly: source inspection shows current main skips builtin memory in both the post-attach scheduler and startup helper, so the central prewarm path is absent. I did not establish a live successful local-model timing reproduction against current main.

Review metrics: 1 noteworthy metric.

Startup policy changed: 1 builtin memory startup mode added. The PR changes post-attach scheduling so explicit builtin/local memory starts work during Gateway startup, which is a user-visible upgrade and availability concern beyond normal CI coverage.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦪 silver shellfish
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P1] Add redacted successful local-model prewarm and first memory_search reuse proof with node-llama-cpp installed.
Rebase and preserve current main's local embedding worker isolation plus provider retry/degraded behavior.
Remove the changelog edit and unrelated Codex test-helper change.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: The supplied terminal output is useful real routing proof for the graceful missing-dependency path, but it does not show a successful local embedding prewarm or first memory_search reuse after the fix; contributors should add redacted terminal output, logs, or a recording from a setup with node-llama-cpp installed, then update the PR body to trigger re-review.

Risk before merge

[P1] Existing explicit-local users would get local embedding worker/model initialization, optional dependency checks or warnings, and possible CPU/RSS/model-cache work immediately after Gateway post-attach instead of only on the first memory_search.
[P1] The PR proof exercises the missing-node-llama-cpp graceful-warning path but not a successful local model load or first-search reuse, so the claimed performance behavior remains unproven in a real setup.
[P1] The branch is old and must be rebased so it preserves current main's child-process local embedding isolation and provider-init retry/degraded behavior.
[P1] The unrelated Codex auth-hint test-helper change and release-owned changelog edit add non-memory churn that maintainers should not land with this startup policy change.

Maintainer options:

Require explicit startup-policy approval and successful proof (recommended)
Before merge, preserve the lazy default or add an owner-approved opt-in/idle policy, then attach redacted output from a setup with node-llama-cpp installed showing successful prewarm and first memory_search reuse.
Accept eager local startup for explicit-local configs
Maintainers can intentionally accept earlier local embedding startup cost and warnings for explicit-local users, but that should be recorded as a product/runtime decision with upgrade proof.
Pause until local memory install/update work settles
Because related local embedding install and startup reports remain active, maintainers can pause or close this branch if prewarm is not worth the startup-risk tradeoff right now.

Next step before merge

[P1] The remaining work is maintainer startup-policy judgment plus contributor proof/rebase cleanup, not a narrow automated repair lane.

Security
Cleared: The diff does not add dependencies, scripts, permissions, secret handling, or new third-party code execution; the concrete concerns are startup availability and compatibility rather than security.

Review findings

[P1] Preserve lazy local memory startup until policy is settled — src/gateway/server-startup-post-attach.ts:81-82
[P3] Remove the release-owned changelog entry — CHANGELOG.md:104
[P3] Drop the unrelated Codex auth-hint relaxation — src/plugins/provider-runtime.test-support.ts:50-61

Review details

Best possible solution:

Land a rebased, memory-only change only after maintainers choose the startup policy and the PR proves successful local prewarm plus first-search reuse while preserving current worker isolation; otherwise keep builtin local memory lazy by default.

Do we have a high-confidence way to reproduce the issue?

Partly: source inspection shows current main skips builtin memory in both the post-attach scheduler and startup helper, so the central prewarm path is absent. I did not establish a live successful local-model timing reproduction against current main.

Is this the best way to solve the issue?

No: the implementation is a plausible mitigation, but not yet the best merge shape because it forces eager local startup work for existing explicit-local configs without successful real proof or a settled startup policy.

Full review comments:

[P1] Preserve lazy local memory startup until policy is settled — src/gateway/server-startup-post-attach.ts:81-82
This makes every builtin memory config with an explicit local provider schedule immediate prewarm after post-attach. Current main only schedules QMD here, and local embeddings now initialize through a worker that can still perform optional-dependency checks and heavy model work; keep the existing lazy behavior or add an owner-approved opt-in/idle policy with successful local-model proof before moving that cost into Gateway startup.
Confidence: 0.84
[P3] Remove the release-owned changelog entry — CHANGELOG.md:104
Normal PRs should not edit CHANGELOG.md; release generation owns this file. Keep the release-note context in the PR body or squash message instead of landing a manual changelog line with this branch.
Confidence: 0.95
[P3] Drop the unrelated Codex auth-hint relaxation — src/plugins/provider-runtime.test-support.ts:50-61
This memory startup PR also changes the shared Codex provider test helper to seed openai-codex profiles and accept openai-codex/gpt-5.5. OpenClaw keeps OpenAI Codex folded into openai, so this unrelated relaxation can mask auth-routing regressions and should be removed or handled in a separate Codex-focused PR.
Confidence: 0.78

Overall correctness: patch is incorrect
Overall confidence: 0.84

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 03a8d18cd434.

Label changes

Label justifications:

P1: The PR changes Gateway startup behavior for local memory users and can affect first-run availability on real constrained or missing-dependency setups.
merge-risk: 🚨 compatibility: Existing explicit-local configurations would observe local embedding dependency checks and warmup warnings during startup rather than at first memory search.
merge-risk: 🚨 availability: Local model initialization can consume CPU, memory, and worker lifecycle resources during Gateway post-attach, so green unit tests do not settle startup availability risk.
rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦪 silver shellfish.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The supplied terminal output is useful real routing proof for the graceful missing-dependency path, but it does not show a successful local embedding prewarm or first memory_search reuse after the fix; contributors should add redacted terminal output, logs, or a recording from a setup with node-llama-cpp installed, then update the PR body to trigger re-review.

Evidence reviewed

PR surface:

Source +79, Tests +134, Docs +1. Total +214 across 8 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	4	107	28	+79
Tests	3	139	5	+134
Docs	1	1	0	+1
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	8	247	33	+214

What I checked:

Repository policy read and applied: Root AGENTS.md and scoped gateway/extensions/plugins AGENTS.md were read fully; the review applies the OpenClaw rules that startup/config/provider behavior is compatibility-sensitive, changelog edits are release-owned, and Codex-related verdicts require checking sibling Codex source. (AGENTS.md:12, 03a8d18cd434)
Current main does not implement the requested builtin-local prewarm: On current origin/main, Gateway post-attach memory startup returns off whenever cfg.memory?.backend !== "qmd", so builtin memory is not scheduled by this policy. (src/gateway/server-startup-post-attach.ts:154, 03a8d18cd434)
Current main memory startup helper is QMD-only: startGatewayMemoryBackend on current main continues unless the resolved backend is QMD, confirming the central PR behavior is not already implemented on main. (src/gateway/server-startup-memory.ts:59, 03a8d18cd434)
PR changes the Gateway startup policy for builtin local memory: The PR head makes builtin or omitted memory backend return { mode: "immediate" } when a local memory provider is configured, which changes when existing explicit-local setups pay local embedding startup work. (src/gateway/server-startup-post-attach.ts:80, a0ccc6108e6e)
PR prewarms the cached default builtin manager: The PR calls getActiveMemorySearchManager without a transient purpose for builtin local, then calls probeEmbeddingAvailability; that is the behavior needed for reuse, but also the point that can spawn/check the local embedding runtime during startup. (src/gateway/server-startup-memory.ts:113, a0ccc6108e6e)
Current main isolates local embeddings in a child worker: Current main's local embedding provider uses a parent-side child-process worker and initializes the provider through IPC; a rebase must preserve this isolation before moving local work earlier in the Gateway lifecycle. (packages/memory-host-sdk/src/host/embeddings-worker.ts:165, 03a8d18cd434)

Likely related people:

vincentkoc: Current main blame for the gateway memory startup helper, post-attach startup policy, MemoryIndexManager retry code, and local embedding worker points to the latest release-baseline work by Vincent Koc. (role: recent area contributor; confidence: high; commits: c7b01cf201f7, 2e08f0f4221f; files: src/gateway/server-startup-memory.ts, src/gateway/server-startup-post-attach.ts, extensions/memory-core/src/memory/manager.ts)
vignesh07: The QMD eager-start memory backend path that this PR extends appears in commit efc79f69a2, authored by Vignesh Natarajan. (role: introduced adjacent startup behavior; confidence: medium; commits: efc79f69a268; files: src/gateway/server-startup-memory.ts, src/gateway/server-startup.ts)
gumadeiras: The post-attach startup seam containing resolveGatewayMemoryStartupPolicy was split into its current shape by Gustavo Madeira Santana in 8de63ca268. (role: adjacent gateway startup owner; confidence: medium; commits: 8de63ca26825; files: src/gateway/server-startup-post-attach.ts)
steipete: The bundled memory engine move into the memory plugin is tied to Peter Steinberger's cad83db8b2, and the PR discussion already asked for his startup-policy guidance. (role: memory architecture contributor; confidence: medium; commits: cad83db8b2f7; files: extensions/memory-core/src/memory/manager.ts, packages/memory-host-sdk/src/host)
osolmaz: The live PR timeline shows the item assigned to osolmaz on 2026-06-03, which is a routing signal even though the code history is shared. (role: likely follow-up owner; confidence: medium; files: src/gateway/server-startup-memory.ts, src/gateway/server-startup-post-attach.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

taosiyuan163 · 2026-05-12T07:28:43Z

Rebased this PR onto current main and pushed a retry-safe follow-up for the Clawsweeper findings.

What changed:

kept the current QMD startup boot-sync / defer / purpose: "cli" behavior intact on latest main
prewarm builtin memory only for explicit memorySearch.provider = "local"
fixed builtin manager provider-init lifecycle so a transient startup prewarm failure does not poison the cached default manager for later real memory_search calls
added a regression test for failure-then-retry provider initialization
added the changelog entry

Local verification:

pnpm exec oxfmt --check --threads=1 src/gateway/server-startup-memory.ts src/gateway/server-startup-memory.test.ts extensions/memory-core/src/memory/manager.ts extensions/memory-core/src/memory/index.test.ts src/plugins/provider-runtime.test-support.ts CHANGELOG.md
pnpm test -- src/gateway/server-startup-memory.test.ts
pnpm test -- extensions/memory-core/src/memory/index.test.ts extensions/memory-core/src/memory/search-manager.test.ts
pnpm test -- src/plugins/provider-runtime.test.ts extensions/openai/provider-catalog.contract.test.ts
pnpm build

taosiyuan163 · 2026-05-12T07:53:21Z

Pushed another update for the Clawsweeper scheduler finding.

Additional fix:

wired builtin explicit-local memory into resolveGatewayMemoryStartupPolicy, so the real post-attach gateway scheduler now imports/calls startGatewayMemoryBackend for builtin local memory instead of only QMD
added post-attach scheduler coverage proving builtin local schedules immediate memory startup and builtin non-local stays off

Updated local verification:

pnpm exec oxfmt --check --threads=1 src/gateway/server-startup-post-attach.ts src/gateway/server-startup-post-attach.test.ts src/gateway/server-startup-memory.ts src/gateway/server-startup-memory.test.ts extensions/memory-core/src/memory/manager.ts extensions/memory-core/src/memory/index.test.ts src/plugins/provider-runtime.test-support.ts CHANGELOG.md
pnpm test -- src/gateway/server-startup-post-attach.test.ts src/gateway/server-startup-memory.test.ts
pnpm test -- extensions/memory-core/src/memory/index.test.ts extensions/memory-core/src/memory/search-manager.test.ts
pnpm test -- src/plugins/provider-runtime.test.ts extensions/openai/provider-catalog.contract.test.ts
pnpm build

taosiyuan163 · 2026-05-12T07:55:08Z

Added one more real-output check for the post-attach scheduler wiring on the latest head:

module: server-startup-post-attach-B-tVxbry.js
exports: __testing, startGatewayPostAttachRuntime, startGatewaySidecars
policy builtin/local: {"mode":"immediate"}
policy builtin/auto: {"mode":"off"}

This is from the production build output after pnpm build, confirming the real post-attach startup policy now schedules builtin explicit-local memory startup while keeping builtin non-local off.

taosiyuan163 · 2026-05-12T08:03:13Z

@clawsweeper re-review

Latest head a0ccc6108e6e5372a656072a7db2b313874fd1ae addresses the prior scheduler finding and adds the requested real behavior proof in the PR body. CI is green, including Real behavior proof, check, check-additional, build-smoke, CodeQL Critical Quality memory/network/provider shards, Opengrep, and security checks.

clawsweeper · 2026-05-12T08:04:45Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/25721706575
Updated: 2026-05-12T08:12:54.283Z

taosiyuan163 · 2026-05-15T14:33:52Z

CI is green, but ClawSweeper's latest blocker looks like an owner-level call rather than a test failure: the PR moves explicit builtin/local prewarm into Gateway startup, while #75657 argues the current in-process node-llama-cpp / GGUF load path can still block the event loop.

@steipete could you take a look and advise whether this branch should:

stay blocked until the local embedding isolation work lands,
be narrowed to avoid the startup prewarm path, or
still be acceptable to merge as-is for explicit-local configs?

Happy to rework the PR in whichever direction matches the intended runtime boundary.

openclaw-barnacle · 2026-06-05T05:05:35Z