docs: register plugin kind before activating it in the plugin guide#200
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (2)
📜 Recent review details⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🧰 Additional context used📓 Path-based instructions (11){docs/**,README.md,CONTRIBUTING.md}📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Files:
{docs/**,README.md,CONTRIBUTING.md,**/*.md}📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Files:
{docs/**,README.md}📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Files:
{docs/**,examples/**,README.md}📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Files:
{docs/**,README.md,**/Cargo.toml,**/package.json,**/*.md}📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Files:
**/*.{md,mdx,py,sh,yaml,yml,toml,json}📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Files:
**/*.mdx📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Files:
**/*.{html,md,mdx}📄 CodeRabbit inference engine (CONTRIBUTING.md)
Files:
docs/**/*.{md,mdx}📄 CodeRabbit inference engine (CONTRIBUTING.md)
Files:
docs/**📄 CodeRabbit inference engine (CONTRIBUTING.md)
Files:
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}⚙️ CodeRabbit configuration file
Files:
🔇 Additional comments (2)
WalkthroughThis PR updates plugin initialization documentation to clarify that component kinds must be registered before calling ChangesPlugin Initialization Validation Documentation
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
The "Register Plugin Behavior" guide showed the Activation APIs example (build, validate, initialize) ahead of the Header Plugin Example that registers the `header-plugin` kind. Run on its own, the activation snippet failed with `RuntimeError: ... 'header-plugin' is not registered`, and the "Validate Plugin Configuration" pre-flight did not catch it: an unregistered kind is only a warning under the default `unknown_component="warn"` policy, so the error-only `has_errors` check passed while `initialize()` raised. Reorder register-behavior.mdx so the Header Plugin Example (which registers the kind) precedes the Activation APIs lifecycle, drop the now-redundant "register the plugin kind" list item, and document the validate-warns / initialize-raises behavior in both the register-behavior and validate-configuration guides. The reorder moves whole sections only; no code-block content changed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Zhongxuan Wang <daniewang@nvidia.com>
zhongxuanwang-nv
force-pushed
the
docs/plugin-register-before-activate
branch
from
04a1c79 to
e742610
Compare
|
/merge |
|
/merge |
…VIDIA#200) #### Overview Reorder the "Register Plugin Behavior" guide so a plugin kind is registered before it is activated, and document the `validate()`-warns / `initialize()`-raises behavior. Run on its own, the **Activation APIs** example previously failed with `RuntimeError: ... 'header-plugin' is not registered`, because the kind it activates is only registered later on the page in the **Header Plugin Example**. - [x] I confirm this contribution is my own work, or I have the right to submit it under this project's license. - [x] I searched existing issues and open pull requests, and this does not duplicate existing work. #### Details - `docs/build-plugins/register-behavior.mdx`: move the **Header Plugin Example** (which calls `plugin.register("header-plugin", ...)`) above the **Activation APIs** lifecycle so the page reads and runs top to bottom. Drop the now-redundant "Register the plugin kind" item from the activation list, and note that an unregistered kind is reported by `validate()` only as a warning under the default `unknown_component="warn"` policy, while `initialize()` raises. The reorder moves whole sections only; no code-block content changed (verified by an order-independent line diff). - `docs/build-plugins/validate-configuration.mdx`: add the same clarification to **Validate Before Initialization** — the error-only `has_errors` check does not catch an unknown/unregistered kind; register kinds first, or set `unknown_component="error"`. Heads-up: this edits the same `register-behavior.mdx` **Activation APIs** section as NVIDIA#199 (which adds `plugin.layer(...)` to that example but does not change the registration ordering). The two overlap, so whichever lands second will need a small conflict resolution. #### Where should the reviewer start? `docs/build-plugins/register-behavior.mdx` — confirm the section reorder preserved every code block (an order-independent line diff shows only the numbered list and intro changed) and that the Activation APIs example now follows the Header Plugin Example that registers the kind. Verified locally: running the Header Plugin Example block and then the Activation APIs block in one process registers `header-plugin`, after which `validate()` / `initialize()` / `clear()` succeed with empty diagnostics and no `RuntimeError`. Targeted `pre-commit` (trailing whitespace, end-of-files, docs markdown linkcheck) passes on both files. #### Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to) - Relates to: NVIDIA#199 (edits the same `register-behavior.mdx` section) ## Summary by CodeRabbit * **Documentation** * Clarified that plugin kinds must be registered before calling initialize() * Explained that unknown/unregistered component kinds are reported as warnings by default during validation and may still cause errors at initialization unless policy is changed * Reorganized and updated the activation guide and language across Python/Node/Rust examples for clearer ordering and guidance Authors: - Zhongxuan (Daniel) Wang (https://github.com/zhongxuanwang-nv) Approvers: - Will Killian (https://github.com/willkill07) URL: NVIDIA#200 Signed-off-by: Yuchen Zhang <yuchenz@nvidia.com>
2 participants
Overview
Reorder the "Register Plugin Behavior" guide so a plugin kind is registered before it is activated, and document the
validate()-warns /initialize()-raises behavior. Run on its own, the Activation APIs example previously failed withRuntimeError: ... 'header-plugin' is not registered, because the kind it activates is only registered later on the page in the Header Plugin Example.Details
docs/build-plugins/register-behavior.mdx: move the Header Plugin Example (which callsplugin.register("header-plugin", ...)) above the Activation APIs lifecycle so the page reads and runs top to bottom. Drop the now-redundant "Register the plugin kind" item from the activation list, and note that an unregistered kind is reported byvalidate()only as a warning under the defaultunknown_component="warn"policy, whileinitialize()raises. The reorder moves whole sections only; no code-block content changed (verified by an order-independent line diff).docs/build-plugins/validate-configuration.mdx: add the same clarification to Validate Before Initialization — the error-onlyhas_errorscheck does not catch an unknown/unregistered kind; register kinds first, or setunknown_component="error".Heads-up: this edits the same
register-behavior.mdxActivation APIs section as #199 (which addsplugin.layer(...)to that example but does not change the registration ordering). The two overlap, so whichever lands second will need a small conflict resolution.Where should the reviewer start?
docs/build-plugins/register-behavior.mdx— confirm the section reorder preserved every code block (an order-independent line diff shows only the numbered list and intro changed) and that the Activation APIs example now follows the Header Plugin Example that registers the kind.Verified locally: running the Header Plugin Example block and then the Activation APIs block in one process registers
header-plugin, after whichvalidate()/initialize()/clear()succeed with empty diagnostics and noRuntimeError. Targetedpre-commit(trailing whitespace, end-of-files, docs markdown linkcheck) passes on both files.Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
register-behavior.mdxsection)Summary by CodeRabbit