PR #74480: fix(active-memory): preserve setup grace for embedded recall

• Repository: openclaw/openclaw
• Author: volcano303
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74480

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: Active Memory could time out at the raw configured recall timeout because the embedded recall runner did not receive the setup-grace timeout budget.
• Why it matters: This made provider-agnostic Active Memory runs fail around 15s with empty output even though the plugin wrapper already intended to allow setup grace.
• What changed: Active Memory now uses one effective embedded recall timeout equal to timeoutMs + setupGraceTimeoutMs for the embedded runner, outer watchdog, and hook timeout.
• What did NOT change (scope boundary): This does not change memory search behavior, provider routing, circuit breaker semantics, or the configured timeoutMs clamp itself.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #73306
• Related #74292
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Active Memory computed a setup-grace-aware timeout for the outer watchdog and hook, but passed only config.timeoutMs into runEmbeddedPiAgent, allowing the embedded runner to self-timeout before the grace window could help.
• Missing detection / guardrail: The setup-grace regression test did not assert that the embedded runner itself received the grace-extended timeout.
• Contributing context (if known): Recent fixes added memory_recall, circuit breaker behavior, and setup-grace handling, but the timeout budget was not applied consistently across the embedded runner boundary.

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: extensions/active-memory/index.test.ts
• Scenario the test should lock in: Active Memory setup delay longer than raw timeoutMs but within setup grace should still succeed, and runEmbeddedPiAgent should receive timeoutMs + setupGraceTimeoutMs.
• Why this is the smallest reliable guardrail: The bug is at the plugin-to-embedded-runner timeout handoff, so a focused plugin unit test catches it without requiring a live provider.
• Existing test that already covers this (if any): Existing setup-grace test covered the outer behavior but not the embedded runner timeout argument.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Active Memory recall gets the intended setup-grace budget before timing out, reducing false 15s timeout failures during embedded runner startup/setup.

Diagram (if applicable)

Before:
Active Memory timeoutMs=15000 -> embedded runner timeoutMs=15000 -> setup can consume budget -> timeout

After:
Active Memory timeoutMs=15000 + setup grace -> embedded runner gets effective timeout -> recall can complete within grace window

Security Impact (required)

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

Repro + Verification

Environment

• OS: Linux
• Runtime/container: Node 22.14.0, pnpm
• Model/provider: Not required for unit verification
• Integration/channel (if any): Active Memory plugin
• Relevant config (redacted): active-memory.timeoutMs with setup grace enabled

Steps

1. Configure Active Memory with a small timeoutMs.
2. Simulate embedded recall setup taking longer than raw timeoutMs but less than timeoutMs + setupGraceTimeoutMs.
3. Run the Active Memory plugin tests.

Expected

• Embedded recall receives the setup-grace-extended timeout.
• Recall can succeed when setup delay fits inside the grace window.

Actual

• Before this PR, the embedded runner received only raw timeoutMs.
• After this PR, the embedded runner receives timeoutMs + setupGraceTimeoutMs.

Evidence

Attach at least one:

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

Compatibility / Migration

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

Risks and Mitigations

• Risk: Active Memory embedded recall may run longer than operators expect if they interpreted timeoutMs as a hard total wall-clock limit.
• Mitigation: This matches the existing setup-grace design already used by the outer watchdog and hook timeout; the configured timeout clamp and circuit breaker remain in place.

Verification commands to mention if needed:

```bash
pnpm test:fast extensions/active-memory/index.test.ts
pnpm test:fast extensions/active-memory/config.test.ts
pnpm exec oxlint extensions/active-memory/index.ts extensions/active-memory/index.test.ts
git diff --check

## Changed files

- `extensions/active-memory/index.test.ts` (modified, +13/-7)
- `extensions/active-memory/index.ts` (modified, +9/-3)