feat: update the limits of plugins#2153
Conversation
WalkthroughUpdated billing.json to change plugin quotas across plans (Developer: 3; Launch: 10; Scale: 20; Enterprise: 30). Tests were revised to pre-create plugins up to new limits and assert ERR_LIMIT_REACHED beyond. Added DEFAULT_NAMESPACE export in test-util.js and used it in publish-subgraph tests. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (2)
140-153: Good limit setup; consider extracting a tiny helper to remove duplicationLooping to pre-create 3 plugins is correct for developer@1. This pattern repeats across multiple tests in this PR; a small helper would keep tests concise and consistent.
Example: add a local helper in this file and use it here:
async function createPlugin(client: any, name: string, labelPrefix = 'team') { const pluginLabel = genUniqueLabel(labelPrefix); const resp = await client.createFederatedSubgraph({ name, namespace: DEFAULT_NAMESPACE, type: SubgraphType.GRPC_PLUGIN, labels: [pluginLabel], }); expect(resp.response?.code).toBe(EnumStatusCode.OK); return resp; }Then replace the loop with:
for (let i = 1; i <= 3; i++) { await createPlugin(client, genID(`plugin-${i}`), `team-${i}`); }
135-139: Outdated inline comment about developer plan plugin limitThe comment still says “0 plugin limit” while the plan enforces 3. Update to avoid confusion.
- setupBilling: { plan: 'developer@1' }, // Developer plan has 0 plugin limit + setupBilling: { plan: 'developer@1' }, // Developer plan allows max 3 pluginscontrolplane/test/feature-subgraph/create-feature-subgraph.test.ts (1)
453-455: Fix stale comment referencing “launch plan” limitThis test uses developer@1; the inline comment still references “launch plan”.
- // Now we have 3 plugins (the limit for launch plan) + // Now we have 3 plugins (the limit for developer plan)controlplane/test/subgraph/publish-subgraph.test.ts (2)
482-496: DRY: reuse the existing createPluginSubgraph helper in this loopYou already defined createPluginSubgraph above; use it to reduce repetition and local label handling here.
- // Create 3 plugins successfully - for (let i = 1; i <= 3; i++) { - const pluginName = genID(`plugin-${i}`); - const pluginLabel = genUniqueLabel(`team-${i}`); - - const createPluginSubgraphResp = await client.createFederatedSubgraph({ - name: pluginName, - namespace: DEFAULT_NAMESPACE, - type: SubgraphType.GRPC_PLUGIN, - labels: [pluginLabel], - }); - - expect(createPluginSubgraphResp.response?.code).toBe(EnumStatusCode.OK); - } + // Create 3 plugins successfully + for (let i = 1; i <= 3; i++) { + await createPluginSubgraph(client, genID(`plugin-${i}`), DEFAULT_NAMESPACE); + }
501-507: Prefer DEFAULT_NAMESPACE constant over string literalMinor consistency nit: you use DEFAULT_NAMESPACE elsewhere in this test; use it here too.
- namespace: 'default', + namespace: DEFAULT_NAMESPACE,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
controlplane/src/bin/billing.json(4 hunks)controlplane/test/feature-subgraph/create-feature-subgraph.test.ts(1 hunks)controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts(1 hunks)controlplane/test/subgraph/create-subgraph.test.ts(3 hunks)controlplane/test/subgraph/publish-subgraph.test.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (2)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (1)
DEFAULT_NAMESPACE(52-52)
controlplane/test/subgraph/create-subgraph.test.ts (2)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (2)
DEFAULT_NAMESPACE(52-52)SetupTest(66-417)
controlplane/test/subgraph/publish-subgraph.test.ts (2)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (1)
DEFAULT_NAMESPACE(52-52)
⏰ 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)
- GitHub Check: build_test
- GitHub Check: Analyze (go)
🔇 Additional comments (8)
controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (1)
159-162: Assertion target updated to the 4th plugin looks correctUsing the 4th plugin’s name and labels to trigger ERR_LIMIT_REACHED aligns with the revised limits.
controlplane/src/bin/billing.json (3)
32-36: Developer plan: plugins feature addition looks goodAdding a “plugins” feature with limit 3 matches the updated tests and intended plan behavior.
80-82: Launch plan: increased plugin limit to 10 is consistentThe new “10 Plugins” description and limit: 10 align with the expanded tests.
132-134: Scale plan: increased plugin limit to 20 is consistentDescription and limit both reflect 20 plugins; aligns with PR intent.
controlplane/test/feature-subgraph/create-feature-subgraph.test.ts (1)
421-422: Plan switched to developer@1 is appropriate for a 3-plugin limit scenarioComment also clearly reflects the max of 3. Looks good.
controlplane/test/subgraph/create-subgraph.test.ts (3)
578-591: Developer plan limit path: assertions and flow look correctPre-creating 3 plugins and asserting ERR_LIMIT_REACHED on the 4th matches the updated developer@1 quota.
Also applies to: 593-605
615-617: Launch plan limit path extended to 10: looks goodCreating 10 plugins and failing on the 11th accurately tests the new limit.
Also applies to: 630-643
816-829: Verifying limits apply only to plugins is a valuable additionGood coverage to ensure regular and event-driven subgraphs are unaffected by plugin quotas.
Also applies to: 842-844
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
controlplane/src/bin/billing.json (1)
1-186: Docs sync for plan changesMultiple plan quotas changed. Please ensure cosmo-docs are updated to prevent drift between product behavior and documentation.
I can prepare a doc change summary listing plan → plugin caps (dev: 3, launch: 10, scale: 20, enterprise: 30/unlimited). Want me to draft it?
controlplane/test/feature-subgraph/create-feature-subgraph.test.ts (1)
453-454: Nit: comment mentions “launch plan” but test uses developer planUpdate the inline comment for clarity.
- // Now we have 3 plugins (the limit for launch plan) + // Now we have 3 plugins (the limit for the developer plan)controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (1)
137-138: Nit: outdated comment about developer plugin limitComment says “0 plugin limit” but the test uses the new 3-plugin cap.
- setupBilling: { plan: 'developer@1' }, // Developer plan has 0 plugin limit + setupBilling: { plan: 'developer@1' }, // Developer plan has a 3 plugin limitcontrolplane/test/subgraph/publish-subgraph.test.ts (1)
500-507: Nit: use DEFAULT_NAMESPACE constant instead of string literalMinor consistency improvement within the same test.
- namespace: 'default', + namespace: DEFAULT_NAMESPACE,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
controlplane/src/bin/billing.json(4 hunks)controlplane/test/feature-subgraph/create-feature-subgraph.test.ts(1 hunks)controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts(1 hunks)controlplane/test/subgraph/create-subgraph.test.ts(3 hunks)controlplane/test/subgraph/publish-subgraph.test.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (2)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (1)
DEFAULT_NAMESPACE(52-52)
controlplane/test/subgraph/create-subgraph.test.ts (3)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (2)
DEFAULT_NAMESPACE(52-52)SetupTest(66-417)connect-go/gen/proto/wg/cosmo/common/common.pb.go (4)
EnumStatusCode(23-23)EnumStatusCode(103-105)EnumStatusCode(107-109)EnumStatusCode(116-118)
controlplane/test/subgraph/publish-subgraph.test.ts (2)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (1)
DEFAULT_NAMESPACE(52-52)
🔇 Additional comments (13)
controlplane/src/bin/billing.json (4)
31-36: Add developer plan plugin limit (3) — looks goodIntroducing the plugins feature to developer@1 with a cap of 3 aligns with the updated tests and the intended plan differentiation.
79-82: Increase Launch plan plugin limit to 10 — OKQuota bump to 10 matches the revised tests and provides a sensible progression between plans.
131-134: Increase Scale plan plugin limit to 20 — OKConsistent with the tiering and the test coverage in this PR.
179-182: “Unlimited Plugins” description conflicts with numeric limit (30) — confirm intent and align configDescription says “Unlimited Plugins” but the limit is 30. Please either:
- Represent “unlimited” according to how the control plane enforces limits (e.g., omit limit, use null/-1/sentinel), or
- Keep the numeric limit and align the description to “30 Plugins”.
Proposed diffs for either approach:
Option A (keep 30, fix description):
- "description": "Unlimited Plugins", - "limit": 30 + "description": "30 Plugins", + "limit": 30Option B (make it truly unlimited if supported by enforcement logic):
- "description": "Unlimited Plugins", - "limit": 30 + "description": "Unlimited Plugins"Also, the checklist shows docs not updated. If “Unlimited” semantics change, ensure docs reflect the new behavior.
controlplane/test/feature-subgraph/create-feature-subgraph.test.ts (1)
421-421: Switch to developer@1 for plugin-limit test — good alignmentUsing developer@1 here correctly exercises the 3-plugin cap introduced in billing.json.
controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (2)
140-153: Pre-create 3 plugins before triggering limit — correctThe loop setup mirrors the developer@1 cap. Assertions are precise and deterministic.
158-162: Inputs for the 4th plugin attempt — OKNaming/labeling is clear; using DEFAULT_NAMESPACE is consistent with other tests.
controlplane/test/subgraph/publish-subgraph.test.ts (3)
15-15: Import DEFAULT_NAMESPACE — OKGood step toward centralizing “default” namespace usage across tests.
476-482: Use developer@1 for publish-limit test — OKTargets the correct tier to exercise the 3-plugin cap.
482-495: Pre-create 3 plugins via loop — OKStraightforward setup; keeps the test concise.
controlplane/test/subgraph/create-subgraph.test.ts (3)
578-605: Developer plan plugin cap (3) test — OKLoop-based creation + precise error assertions make the intent clear.
609-643: Launch plan plugin cap (10) test — OKGood coverage for the increased Launch quota and the failure at 11.
816-829: Verify plugin limits don’t affect regular/EDG subgraphs — OKUseful guardrail to ensure scoping of plugin quotas.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (8)
controlplane/test/feature-subgraph/create-feature-subgraph.test.ts (1)
421-422: Plan switched to developer@1 — update the nearby comment to avoid confusionThe plan change is correct for validating the 3-plugin limit. However, later in this test (comment near Line 453) it still says “the limit for launch plan”. Update that comment to “developer plan” to prevent confusion during maintenance.
controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (1)
140-157: Avoid magic numbers for plan limits; derive locally and reuseThe loop pre-creates three plugins to reach the Developer limit. Introduce a local constant and derive the “4th” attempt from it to reduce drift if plan limits change again. Also update the earlier inline comment (near Line 137) to “Developer plan has 3 plugin limit”.
Apply this diff:
- // Create 3 plugins successfully - for (let i = 1; i <= 3; i++) { + const MAX_DEV_PLUGINS = 3; + // Create plugins up to the developer plan limit + for (let i = 1; i <= MAX_DEV_PLUGINS; i++) { const pluginName = genID(`plugin-${i}`); const pluginLabel = genUniqueLabel(`team-${i}`); const createPluginSubgraphResp = await client.createFederatedSubgraph({ name: pluginName, namespace: DEFAULT_NAMESPACE, type: SubgraphType.GRPC_PLUGIN, labels: [pluginLabel], }); expect(createPluginSubgraphResp.response?.code).toBe(EnumStatusCode.OK); } - - const fourthPluginName = genID('plugin-4'); - const fourthPluginLabel = genUniqueLabel('team-4'); + const fourthPluginName = genID(`plugin-${MAX_DEV_PLUGINS + 1}`); + const fourthPluginLabel = genUniqueLabel(`team-${MAX_DEV_PLUGINS + 1}`);controlplane/test/subgraph/create-subgraph.test.ts (4)
578-591: Dev plan plugin pre-population — replace magic number with a named constantDefine a local MAX_DEV_PLUGINS to avoid scattering “3” across the test and improve maintainability.
Apply this diff:
- // Create 3 plugins successfully - for (let i = 1; i <= 3; i++) { + const MAX_DEV_PLUGINS = 3; + // Create plugins up to the developer plan limit + for (let i = 1; i <= MAX_DEV_PLUGINS; i++) { const pluginName = genID(`plugin-${i}`); const pluginLabel = genUniqueLabel(`team-${i}`); const createPluginSubgraphResp = await client.createFederatedSubgraph({ name: pluginName, namespace: DEFAULT_NAMESPACE, type: SubgraphType.GRPC_PLUGIN, labels: [pluginLabel], }); expect(createPluginSubgraphResp.response?.code).toBe(EnumStatusCode.OK); }
593-605: Dev plan “4th plugin” — derive from the same constantCompute the “4th” plugin name/label based on MAX_DEV_PLUGINS defined above to keep the test resilient to future limit changes.
Apply this diff:
- const fourthPluginName = genID('plugin-4'); - const fourthPluginLabel = genUniqueLabel('team-4'); + const fourthPluginName = genID(`plugin-${MAX_DEV_PLUGINS + 1}`); + const fourthPluginLabel = genUniqueLabel(`team-${MAX_DEV_PLUGINS + 1}`);
615-643: Launch plan limit — remove magic numbers and derive eleventh attemptIntroduce MAX_LAUNCH_PLUGINS = 10 and use it in both the creation loop and the “11th plugin” assertion.
Apply this diff:
- // Create 10 plugins successfully - for (let i = 1; i <= 10; i++) { + const MAX_LAUNCH_PLUGINS = 10; + // Create plugins up to the launch plan limit + for (let i = 1; i <= MAX_LAUNCH_PLUGINS; i++) { const pluginName = genID(`plugin-${i}`); const pluginLabel = genUniqueLabel(`team-${i}`); @@ - // The 11th plugin should fail due to limit - const eleventhPluginName = genID('plugin-11'); - const eleventhPluginLabel = genUniqueLabel('team-11'); + // The (MAX_LAUNCH_PLUGINS + 1)-th plugin should fail due to limit + const eleventhPluginName = genID(`plugin-${MAX_LAUNCH_PLUGINS + 1}`); + const eleventhPluginLabel = genUniqueLabel(`team-${MAX_LAUNCH_PLUGINS + 1}`);
816-829: “Verify plugin limits only apply to plugins” — reuse the launch limit constantSame suggestion here: avoid embedding 10 in the loop to reduce drift.
Apply this diff:
- // First, create the maximum number of plugins (10 for launch plan) - for (let i = 1; i <= 10; i++) { + const MAX_LAUNCH_PLUGINS = 10; + // First, create the maximum number of plugins for the launch plan + for (let i = 1; i <= MAX_LAUNCH_PLUGINS; i++) { const pluginName = genID(`plugin-${i}`); const pluginLabel = genUniqueLabel(`plugin-${i}`);Optional follow-up: consider extracting a small test helper (e.g., createPlugins(client, n, namespace)) into test-util to remove duplication across multiple files in this PR.
controlplane/test/subgraph/publish-subgraph.test.ts (2)
15-15: Good: use DEFAULT_NAMESPACE import; also use it in helper default to avoid hardcodingThe import looks right. For consistency, update the createPluginSubgraph helper’s default parameter from the hardcoded 'default' to DEFAULT_NAMESPACE.
Consider updating the helper (outside this hunk) like:
async function createPluginSubgraph(client: any, name: string, namespace = DEFAULT_NAMESPACE) { // ... }
479-507: Dev plan publish flow — remove magic numbers and derive the 4th nameMirror the other tests by introducing MAX_DEV_PLUGINS and computing the “4th” plugin dynamically.
Apply this diff:
- // Create 3 plugins successfully - for (let i = 1; i <= 3; i++) { + const MAX_DEV_PLUGINS = 3; + // Create plugins up to the developer plan limit + for (let i = 1; i <= MAX_DEV_PLUGINS; i++) { const pluginName = genID(`plugin-${i}`); const pluginLabel = genUniqueLabel(`team-${i}`); const createPluginSubgraphResp = await client.createFederatedSubgraph({ name: pluginName, namespace: DEFAULT_NAMESPACE, type: SubgraphType.GRPC_PLUGIN, labels: [pluginLabel], }); expect(createPluginSubgraphResp.response?.code).toBe(EnumStatusCode.OK); } - const fourthPluginName = genID('plugin-4'); + const fourthPluginName = genID(`plugin-${MAX_DEV_PLUGINS + 1}`); @@ - name: fourthPluginName, + name: fourthPluginName,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
controlplane/src/bin/billing.json(4 hunks)controlplane/test/feature-subgraph/create-feature-subgraph.test.ts(1 hunks)controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts(1 hunks)controlplane/test/subgraph/create-subgraph.test.ts(3 hunks)controlplane/test/subgraph/publish-subgraph.test.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts (2)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (1)
DEFAULT_NAMESPACE(52-52)
controlplane/test/subgraph/publish-subgraph.test.ts (2)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (1)
DEFAULT_NAMESPACE(52-52)
controlplane/test/subgraph/create-subgraph.test.ts (3)
controlplane/src/core/test-util.ts (2)
genID(53-55)genUniqueLabel(57-59)controlplane/test/test-util.ts (1)
DEFAULT_NAMESPACE(52-52)router/gen/proto/wg/cosmo/common/common.pb.go (4)
EnumStatusCode(23-23)EnumStatusCode(103-105)EnumStatusCode(107-109)EnumStatusCode(116-118)
🔇 Additional comments (3)
controlplane/src/bin/billing.json (3)
31-36: Developer plan plugin quota set to 3 — aligned with expected testsThe feature entry for plugins on the Developer plan is consistent (description and limit both 3). Good update.
80-82: Launch plan plugin quota raised to 10 — looks goodDescription and limit are consistent; matches the intended new quota.
132-134: Scale plan plugin quota raised to 20 — looks goodDescription and limit are consistent and higher than Launch, as expected.
Summary by CodeRabbit
Checklist