Fix/plugin diagnostics orphan cleanup v2#7
Open
ralf003 wants to merge 5 commits into
Open
Conversation
Replace the blanket !pluginId -> stale rule with a targeted orphan-source-path diagnostic code. discovery.ts now sets this code on diagnostics from discoverFromPath, and hasStalePersistedPluginDiagnostics checks the code instead of requiring pluginId to be absent. This avoids treating legitimate diagnostics without pluginId (e.g. package plugin validation warnings, source-overlay diagnostics) as stale, while still correctly invalidating the persisted registry when a configured load path disappears. Fixes: Gateway startup failure when stale plugin diagnostics_json persists after plugin uninstall.
… persistence The PluginDiagnosticSchema Zod schema was missing the 'code' field that discovery.ts now sets on orphan-source-path diagnostics. This caused the code field to be stripped during SQLite read-back via safeParseWithSchema, preventing hasStalePersistedPluginDiagnostics from detecting stale orphan diagnostics in the persisted plugin index. After this fix, diagnostics with code='orphan-source-path' survive the write/read round-trip through the installed plugin index SQLite store, and the snapshot loading fast path correctly invalidates the persisted registry when orphan diagnostics are present.
ClawSweeper P1: existing users upgrading from released/current OpenClaw have SQLite diagnostics_json rows without the .code field (added in PluginDiagnosticSchema as part of this PR). Those rows have no pluginId and no code but an absolute source that doesn't exist — they are conceptually orphan diagnostics that must trigger a registry refresh instead of being silently reused (which blocks Gateway startup). Add a legacy path in hasStalePersistedPluginDiagnostics: when a diagnostic has no pluginId, a missing absolute source, and no code field (undefined), treat it as stale. This is a narrow, explicit check that avoids the blanket !pluginId rule rejected by maintainers on the original openclaw#93467. New test: 'refreshes registry for legacy no-code orphan diagnostics (upgrade from pre-code schema)' — simulates SQLite row exactly as current/released OpenClaw would have written it.
Dependency GuardThis PR changes dependency-related files. Maintainers should confirm these changes are intentional. Changed files:
Maintainer follow-up:
|
Dependency graph changes notedThis PR includes dependency graph changes. The dependency guard is informational because the PR author is a repository admin or a member of
Security review is still recommended before merge when the dependency graph change is intentional. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
What problem does this PR solve?
Why does this matter now?
What is the intended outcome?
What is intentionally out of scope?
What does success look like?
What should reviewers focus on?
Summary guidance
This PR description is the contributor's durable explanation of the change. Write it for human maintainers first; ClawSweeper and Barnacle use the same text to understand intent, proof, risk, and current review state.
Describe the intent and outcome in 2-5 bullets. Avoid restating the diff; reviewers and bots can read the changed files.
If this PR fixes a plugin beta-release blocker, title it
fix(<plugin-id>): beta blocker - <summary>and link the matchingBeta blocker: <plugin-name> - <summary>issue labeledbeta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.Linked context
Which issue does this close?
Closes #
Which issues, PRs, or discussions are related?
Related #
Was this requested by a maintainer or owner?
Linked context guidance
Link the issue, PR, discussion, maintainer request, or owner request that explains why this PR should exist. Maintainer context helps reviewers and automation distinguish intended work from drive-by churn.
Real behavior proof (required for external PRs)
Real behavior proof guidance
External contributors must show after-fix evidence from a real OpenClaw setup. Unit tests, mocks, lint, typechecks, snapshots, and CI are supplemental only.
Screenshots are encouraged even for CLI, console, text, or log changes. Terminal screenshots, copied live output, redacted runtime logs, recordings, and linked artifacts count.
If your environment cannot produce the ideal proof, explain that under
Proof limitations or environment constraintsso reviewers and ClawSweeper can direct the next step properly.Be mindful of private information like IP addresses, API keys, phone numbers, non-public endpoints, or other private details when providing evidence.
Tests and validation
Which commands did you run?
What regression coverage was added or updated?
What failed before this fix, if known?
If no test was added, why not?
Testing guidance
List focused commands, not every incidental check. CI is useful support, but external PRs still need real behavior proof above when behavior changes.
Risk checklist
Did user-visible behavior change? (
Yes/No)Did config, environment, or migration behavior change? (
Yes/No)Did security, auth, secrets, network, or tool execution behavior change? (
Yes/No)What is the highest-risk area?
How is that risk mitigated?
Risk guidance
Use this for author judgment that is not obvious from the diff. ClawSweeper can see touched files, but it cannot know which behavior you think is risky, why the risk is acceptable, or what mitigation reviewers should verify.
Current review state
What is the next action?
What is still waiting on author, maintainer, CI, or external proof?
Which bot or reviewer comments were addressed?
Review state guidance
Keep this as the durable state for review progress. If useful information appears in comments, fold the current next action or blocker back here so maintainers and ClawSweeper do not need to reconstruct state from comment history.