fix: skip bundled plugin load failures in status flows#70326
fix: skip bundled plugin load failures in status flows#70326jason-allen-oneal wants to merge 10 commits intoopenclaw:mainfrom
Conversation
Greptile SummaryThis PR adds error resilience to bundled plugin loading by adding The implementation integrates cleanly with the existing Confidence Score: 5/5Safe to merge — targeted error-handling fix with good regression coverage and no behavioural regressions. All findings are P2 or below. The implementation is minimal, correctly scoped, and mirrors the existing plugin-load pattern. The new test exercises the exact failure path being fixed. No files require special attention. Reviews (1): Last reviewed commit: "fix: skip bundled plugin load failures i..." | Re-trigger Greptile |
|
Maintainer follow-up: this looks merge-ready from current head. Fresh status check:
Single unblock ask: if you agree with swallowing bundled setup factory failures in status/read-only flows, please approve + merge as-is. |
…plugin-load-failure # Conflicts: # CHANGELOG.md
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d61f7beb9a
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } catch (error) { | ||
| const detail = formatErrorMessage(error); | ||
| log.warn(`[channels] failed to load bundled channel ${id}: ${detail}`); | ||
| return undefined; |
There was a problem hiding this comment.
Cache failed bundled plugin loads
After this change, getBundledChannelPluginForRoot converts loader exceptions into undefined but does not memoize that failure, so every later getChannelPlugin(id) call retries entry.loadChannelPlugin() and re-logs the same warning. Because getChannelPlugin is used on hot command/reply paths, a single missing runtime dependency now causes repeated module-load attempts and log spam for the lifetime of the process instead of a one-time failure; please record failed ids (or a null sentinel) so broken bundled plugins are skipped after the first failure.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 91dba930bf
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const detail = formatErrorMessage(error); | ||
| log.warn(`[channels] failed to load bundled channel setup ${id}: ${detail}`); | ||
| return undefined; |
There was a problem hiding this comment.
Distinguish setup load errors from absent plugins
Catching loadSetupPlugin() exceptions and returning undefined here makes downstream callers treat a load failure as “plugin does not exist.” In long-lived processes, getBootstrapChannelPlugin caches that state in missingIds (src/channels/plugins/bootstrap-registry.ts:127-138), so a setup-only channel that fails once can be skipped for the rest of the process instead of being retried after dependencies/runtime state are fixed. Please preserve an error signal (or separate failure sentinel) so bootstrap caching does not memoize recoverable load failures as permanent absence.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e1e946213b
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } catch (error) { | ||
| const detail = formatErrorMessage(error); | ||
| log.warn(`[channels] failed to load bundled channel setup ${id}: ${detail}`); | ||
| return undefined; |
There was a problem hiding this comment.
Preserve setup load errors so secrets can retry
Returning undefined on loadSetupPlugin() exceptions here makes downstream callers treat a load failure as “no setup plugin,” and getBundledChannelSetupSecretsForRoot then caches null (lazySetupSecretsById) for that id. In processes that continue running after a transient/runtime-deps failure is fixed, setup secrets for that channel will stay permanently missing because subsequent reads hit the null cache and never retry the load path; this regresses recoverability for secret discovery/bootstrap flows.
Useful? React with 👍 / 👎.
…plugin-load-failure # Conflicts: # extensions/thread-ownership/index.ts
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fcc2fcf122
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } catch (error) { | ||
| const detail = formatErrorMessage(error); | ||
| log.warn(`[channels] failed to load bundled channel ${id}: ${detail}`); | ||
| return undefined; |
There was a problem hiding this comment.
Avoid treating plugin load errors as missing secrets
Returning undefined on entry.loadChannelPlugin() failures here causes getBundledChannelSecretsForRoot to cache null when loadChannelSecrets is not provided and it falls back to getBundledChannelPluginForRoot(...)? .secrets. Before this change, the exception bubbled and no negative cache entry was written; now a transient runtime/dependency failure is memoized as “no secrets,” so later bootstrap/doctor secret reads will not retry even after the environment is repaired until process restart.
Useful? React with 👍 / 👎.
…plugin-load-failure # Conflicts: # extensions/thread-ownership/index.ts
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3395a2c5db
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } catch (error) { | ||
| const detail = formatErrorMessage(error); | ||
| log.warn(`[channels] failed to load bundled channel setup ${id}: ${detail}`); | ||
| return undefined; |
There was a problem hiding this comment.
Avoid memoizing setup load failures as missing plugins
This new catch converts loadSetupPlugin() exceptions into undefined, which downstream code treats as “plugin absent.” In particular, resolveCachedChannelSetupPlugins caches listBundledChannelSetupPlugins() by registry version (src/channels/plugins/setup-registry.ts:55-66), so one transient setup-load failure now permanently removes that channel from setup UIs/flows for the rest of the process instead of retrying after dependencies or runtime state are fixed.
Useful? React with 👍 / 👎.
|
Fresh validation on current PR head (674cca4), run just now in a clean worktree:\n\n- ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND No package.json (or package.yaml, or package.json5) was found in "/Users/pica/.openclaw/workspace-builder". ✅\n- ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND No package.json (or package.yaml, or package.json5) was found in "/Users/pica/.openclaw/workspace-builder". ✅\n\nNo lint/type/policy regressions in this run.\n\n@openclaw/maintainers could one of you please re-run the PR review pass and mark this merge-ready if it looks good on your side? |
|
Please don’t spam-ping multiple maintainers at once. Be patient, or join our community Discord for help: https://discord.gg/clawd |
|
Fresh re-validation on current PR head (
Latest PR metadata from Maintainer ask: if this aligns with your read, could one maintainer please apply the next merge action (queue/merge) on #70326? |
|
Fresh PR state check just now:
Maintainer ask: if this state is acceptable, please merge #70326; if not, please share the single remaining blocker and I’ll address it right away. |
Summary
Documentation
Verification