PR #64128: [Bug] Plugin services (recall_manager, openviking) fail to register with 'service already registered' after upgrading to 2026.4.5

• Repository: openclaw/openclaw
• Author: ly85206559
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/64128

Description (problem / solution / changelog)

Summary

• Problem: plugin registry assembly could emit a false-positive service already registered diagnostic when the same plugin id re-registered the same service id during snapshot/repeated activation-style loads.
• Why it matters: snapshot and activation passes should be idempotent for a plugin's own service registration; the old behavior produced noisy diagnostics that looked like a real duplicate-owner conflict.
• What changed: src/plugins/registry.ts now treats same-plugin duplicate registerService() calls as idempotent while still rejecting cross-plugin collisions. src/plugins/loader.test.ts adds a regression test for the same-plugin replay case, and CHANGELOG.md records the fix.
• What did NOT change (scope boundary): cross-plugin duplicate service ids still surface an error, and no plugin loading contract outside this narrow service-registration branch changed.

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 #62033
• Related #64128
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: registerService() only keyed on service id and treated any second registration as a duplicate, even when the existing owner was the same plugin being replayed.
• Missing detection / guardrail: there was coverage for cross-plugin duplicate service ids, but not for same-plugin duplicate registration during replay/snapshot-style assembly.
• Contributing context (if known): snapshot/non-activating loads can assemble the same plugin registry path more than once.

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/plugins/loader.test.ts
• Scenario the test should lock in: the same plugin registers the same service id twice and keeps a single service registration without emitting service already registered.
• Why this is the smallest reliable guardrail: it exercises the real plugin loader/registry path that produced the false positive without needing a full gateway run.
• Existing test that already covers this (if any): existing coverage only locked in the cross-plugin duplicate rejection path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Snapshot and activation-style plugin loads no longer emit a spurious service already registered diagnostic when the duplicate registration belongs to the same plugin.

Diagram (if applicable)

Before:
[same plugin load pass 1] -> registerService(shared-service)
[same plugin load pass 2] -> duplicate-owner error diagnostic

After:
[same plugin load pass 1] -> registerService(shared-service)
[same plugin load pass 2] -> idempotent no-op -> no false-positive diagnostic

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:

Repro + Verification

Environment

• OS: Windows 10
• Runtime/container: Node 22+ repo scripts
• Model/provider: N/A
• Integration/channel (if any): plugin loader / registry
• Relevant config (redacted): test plugin allowed through plugins.entries.*.allow

Steps

1. Load a plugin whose register(api) calls api.registerService({ id: shared-service, ... }) twice.
2. Inspect registry.services and registry.diagnostics.
3. Compare that with the existing cross-plugin duplicate-service scenario.

Expected

• Same-plugin duplicate registration is a no-op.
• Cross-plugin duplicate registration still raises service already registered.

Actual

• Before this fix, the same-plugin replay path also emitted the duplicate-service error.

Evidence

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

Human Verification (required)

• Verified scenarios: rebased onto current main, reviewed the final diff to confirm the same-plugin idempotent guard stays narrow, and added loader coverage for the exact replay case Greptile flagged.
• Edge cases checked: cross-plugin duplicate service rejection remains unchanged; same-plugin duplicate registration still leaves a single registry.services entry.
• What you did not verify: I could not complete a local pnpm test src/plugins/loader.test.ts run on this Windows machine because the repo test entrypoint fails before collecting tests with an existing Vitest runner initialization error in test/non-isolated-runner.ts (Class extends value undefined is not a constructor or null). I also ran pnpm build because this touches plugin registry/loader code; that failed in this workspace on pre-existing unrelated unresolved-import warnings across optional extension dependencies before reaching a clean build result.

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)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: making duplicate registration idempotent too broadly could hide a real ownership conflict.
  • Mitigation: the guard only returns early when both the service id and owning pluginId already match; cross-plugin collisions still error and are covered by existing tests.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/plugins/loader.test.ts (modified, +29/-1)
• src/plugins/registry.ts (modified, +5/-0)