Skip to content

feat: update the limits of plugins#2153

Merged
JivusAyrus merged 3 commits intomainfrom
suvij/update-billing-for-plugins
Aug 19, 2025
Merged

feat: update the limits of plugins#2153
JivusAyrus merged 3 commits intomainfrom
suvij/update-billing-for-plugins

Conversation

@JivusAyrus
Copy link
Copy Markdown
Member

@JivusAyrus JivusAyrus commented Aug 19, 2025

Summary by CodeRabbit

  • New Features
    • Developer plan now includes Plugins (up to 3).
    • Launch plan plugin limit increased to 10.
    • Scale plan plugin limit increased to 20.
    • Enterprise plan plugin capacity increased while remaining effectively unlimited for users.
  • Tests
    • Updated tests to reflect new plugin limits across plans.
    • Added scenarios validating limit enforcement during creation and publish flows.
    • Ensured non-plugin subgraphs are unaffected by plugin limits.

Checklist

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Aug 19, 2025

Walkthrough

Updated 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

Cohort / File(s) Summary
Billing plan data updates
controlplane/src/bin/billing.json
Adjusted plugin feature entries: added Developer plan plugins (limit 3); increased Launch to 10, Scale to 20, Enterprise limit to 30 (description “Unlimited Plugins” retained). Data-only changes.
Plugin limit test adjustments
controlplane/test/feature-subgraph/create-feature-subgraph.test.ts, controlplane/test/plugin/validate-and-fetch-plugin-data.test.ts, controlplane/test/subgraph/create-subgraph.test.ts, controlplane/test/subgraph/publish-subgraph.test.ts
Updated tests to reflect new per-plan plugin limits; introduced loops to pre-create plugins up to limits; adjusted expected failures on next creation/publish; added validation of created plugin subgraph type; switched some plans (e.g., to developer@1) for limit scenarios.
Test utilities
controlplane/test/.../test-util.js
Exported DEFAULT_NAMESPACE for use in publish-subgraph tests.

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 Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch suvij/update-billing-for-plugins

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 duplication

Looping 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 limit

The 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 plugins
controlplane/test/feature-subgraph/create-feature-subgraph.test.ts (1)

453-455: Fix stale comment referencing “launch plan” limit

This 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 loop

You 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 literal

Minor 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.

📥 Commits

Reviewing files that changed from the base of the PR and between eb0ec16 and 5112f6d.

📒 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 correct

Using 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 good

Adding a “plugins” feature with limit 3 matches the updated tests and intended plan behavior.


80-82: Launch plan: increased plugin limit to 10 is consistent

The new “10 Plugins” description and limit: 10 align with the expanded tests.


132-134: Scale plan: increased plugin limit to 20 is consistent

Description 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 scenario

Comment 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 correct

Pre-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 good

Creating 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 addition

Good coverage to ensure regular and event-driven subgraphs are unaffected by plugin quotas.

Also applies to: 842-844

Comment thread controlplane/src/bin/billing.json
Copy link
Copy Markdown
Contributor

@StarpTech StarpTech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
controlplane/src/bin/billing.json (1)

1-186: Docs sync for plan changes

Multiple 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 plan

Update 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 limit

Comment 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 limit
controlplane/test/subgraph/publish-subgraph.test.ts (1)

500-507: Nit: use DEFAULT_NAMESPACE constant instead of string literal

Minor 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.

📥 Commits

Reviewing files that changed from the base of the PR and between eb0ec16 and 5112f6d.

📒 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 good

Introducing 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 — OK

Quota bump to 10 matches the revised tests and provides a sensible progression between plans.


131-134: Increase Scale plan plugin limit to 20 — OK

Consistent with the tiering and the test coverage in this PR.


179-182: “Unlimited Plugins” description conflicts with numeric limit (30) — confirm intent and align config

Description 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": 30

Option 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 alignment

Using 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 — correct

The loop setup mirrors the developer@1 cap. Assertions are precise and deterministic.


158-162: Inputs for the 4th plugin attempt — OK

Naming/labeling is clear; using DEFAULT_NAMESPACE is consistent with other tests.

controlplane/test/subgraph/publish-subgraph.test.ts (3)

15-15: Import DEFAULT_NAMESPACE — OK

Good step toward centralizing “default” namespace usage across tests.


476-482: Use developer@1 for publish-limit test — OK

Targets the correct tier to exercise the 3-plugin cap.


482-495: Pre-create 3 plugins via loop — OK

Straightforward setup; keeps the test concise.

controlplane/test/subgraph/create-subgraph.test.ts (3)

578-605: Developer plan plugin cap (3) test — OK

Loop-based creation + precise error assertions make the intent clear.


609-643: Launch plan plugin cap (10) test — OK

Good coverage for the increased Launch quota and the failure at 11.


816-829: Verify plugin limits don’t affect regular/EDG subgraphs — OK

Useful guardrail to ensure scoping of plugin quotas.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 confusion

The 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 reuse

The 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 constant

Define 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 constant

Compute 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 attempt

Introduce 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 constant

Same 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 hardcoding

The 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 name

Mirror 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.

📥 Commits

Reviewing files that changed from the base of the PR and between eb0ec16 and 5112f6d.

📒 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 tests

The 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 good

Description and limit are consistent; matches the intended new quota.


132-134: Scale plan plugin quota raised to 20 — looks good

Description and limit are consistent and higher than Launch, as expected.

Comment thread controlplane/src/bin/billing.json
@JivusAyrus JivusAyrus merged commit dfe6ad7 into main Aug 19, 2025
12 checks passed
@JivusAyrus JivusAyrus deleted the suvij/update-billing-for-plugins branch August 19, 2025 21:24
@Noroth Noroth mentioned this pull request Sep 30, 2025
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants