feat: upgrade connect v1 to v2

[JivusAyrus]

Summary by CodeRabbit

• Chores
  • Upgraded core dependencies: @bufbuild/protobuf to v2.2.2 and @connectrpc/connect to v2.0.0.
  • Refactored internal message serialization and deserialization patterns for improved code consistency.
  • Updated code generation for gRPC services to align with latest Protobuf standards.
  • Modernized request/response handling across internal services.

Checklist

• I have discussed my proposed changes in an issue and have received approval to proceed.
• I have followed the coding standards of the project.
• Tests or benchmarks have been added or updated.
• Documentation has been updated on https://github.com/wundergraph/docs-website.
• I have read the Contributors Guide.

[coderabbitai]

Actionable comments posted: 12

Note

Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.

🟡 Minor comments (9)

docs/superpowers/plans/2026-03-20-connect-v2-upgrade.md-430-433 (1)

430-433: ⚠️ Potential issue | 🟡 Minor

sed -i '' commands are macOS-specific and will fail on many Linux environments.

These bulk-edit commands are brittle for cross-platform contributors/CI. Prefer a portable approach (document GNU/BSD variants or switch to a Node/TS codemod script).

Portable command pattern example

-find controlplane/src/core/bufservices -name '*.ts' -exec sed -i '' "s/import { PlainMessage } from '@bufbuild\/protobuf';//g" {} +
+find controlplane/src/core/bufservices -name '*.ts' -exec sed -i.bak "s/import { PlainMessage } from '@bufbuild\/protobuf';//g" {} + && find controlplane/src/core/bufservices -name '*.bak' -delete

Also applies to: 504-506, 602-604

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/superpowers/plans/2026-03-20-connect-v2-upgrade.md` around lines 430 -
433, The sed -i '' invocations in the bulk-edit steps (the two find/sed commands
operating on controlplane/src/core/bufservices) are macOS/BSD-specific and will
fail on Linux; replace them with a cross-platform solution by either (a)
documenting both BSD and GNU sed variants and using conditional invocation based
on uname, or (b) replacing the two sed-based edits with a Node/TypeScript
codemod script (or npx jscodeshift) that performs the two transformations
(remove "import { PlainMessage }..." and replace PlainMessage<T> → T) across
files; update the documentation lines that reference those find/sed commands to
point to the chosen portable approach and ensure the same change is applied at
the other noted locations (lines referenced as also applies to: 504-506,
602-604).

controlplane/test/subgraph-check-extensions.test.ts-78-78 (1)

78-78: ⚠️ Potential issue | 🟡 Minor

Remove as any casts by using distinct typed variables for each RPC call.

Lines 78 and 96 use as any casts due to reusing a single resp variable across createFederatedSubgraph() and publishFederatedSubgraph() calls, which have incompatible response types. Using separate variables eliminates the type mismatch and the need for the cast, improving type safety in test code.

Suggested fix

-  let resp = await client.createFederatedSubgraph({
+  const createSubgraph1Resp = await client.createFederatedSubgraph({
     name: subgraph1Name,
     namespace: 'default',
     labels: [label],
     routingUrl: 'http://localhost:8082',
   });
-
-  expect(resp.response?.code).toBe(EnumStatusCode.OK);
+  expect(createSubgraph1Resp.response?.code).toBe(EnumStatusCode.OK);
 
-  resp = await client.publishFederatedSubgraph({
+  const publishSubgraph1Resp = await client.publishFederatedSubgraph({
     name: subgraph1Name,
     namespace: 'default',
     schema: subgraph1Schema,
-  }) as any;
+  });
 
-  expect(resp.response?.code).toBe(EnumStatusCode.OK);
+  expect(publishSubgraph1Resp.response?.code).toBe(EnumStatusCode.OK);
@@
-  resp = await client.createFederatedSubgraph({
+  const createSubgraph2Resp = await client.createFederatedSubgraph({
     name: subgraph2Name,
     namespace: 'default',
     labels: [label],
     routingUrl: 'http://localhost:8083',
   });
-
-  expect(resp.response?.code).toBe(EnumStatusCode.OK);
+  expect(createSubgraph2Resp.response?.code).toBe(EnumStatusCode.OK);
 
-  resp = await client.publishFederatedSubgraph({
+  const publishSubgraph2Resp = await client.publishFederatedSubgraph({
     name: subgraph2Name,
     namespace: 'default',
     schema: subgraph2Schema,
-  }) as any;
+  });
 
-  expect(resp.response?.code).toBe(EnumStatusCode.OK);
+  expect(publishSubgraph2Resp.response?.code).toBe(EnumStatusCode.OK);

Per coding guideline **/*.{ts,tsx}: Avoid any type in TypeScript; use specific types or generics.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/test/subgraph-check-extensions.test.ts` at line 78, The test
reuses a single variable `resp` (cast to `as any`) for two incompatible RPC
responses; replace that pattern by declaring distinct typed variables for each
call (e.g., `const respCreate = await createFederatedSubgraph(...)` and `const
respPublish = await publishFederatedSubgraph(...)`) so the compiler infers the
correct response types (or explicitly annotate them with their RPC response
types) and remove the `as any` casts on lines where `createFederatedSubgraph()`
and `publishFederatedSubgraph()` are called.

controlplane/src/core/bufservices/federated-graph/updateFederatedGraph.ts-116-118 (1)

116-118: ⚠️ Potential issue | 🟡 Minor

Use concrete types from UpdateFederatedGraphResponse instead of any[].

These accumulators currently use any[], which violates the coding guideline to avoid any type in TypeScript. The protobuf-generated UpdateFederatedGraphResponse already defines the concrete array types for these fields:

-    const deploymentErrors: any[] = [];
-    let compositionErrors: any[] = [];
-    const compositionWarnings: any[] = [];
+    const deploymentErrors: UpdateFederatedGraphResponse['deploymentErrors'] = [];
+    let compositionErrors: UpdateFederatedGraphResponse['compositionErrors'] = [];
+    const compositionWarnings: UpdateFederatedGraphResponse['compositionWarnings'] = [];

This preserves type safety while maintaining the contract with the RPC response.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/federated-graph/updateFederatedGraph.ts`
around lines 116 - 118, Replace the loose any[] types for the accumulators with
the concrete protobuf-generated types from UpdateFederatedGraphResponse: change
deploymentErrors, compositionErrors, and compositionWarnings to use
UpdateFederatedGraphResponse['deployment_errors'],
UpdateFederatedGraphResponse['composition_errors'], and
UpdateFederatedGraphResponse['composition_warnings'] respectively (e.g. let
deploymentErrors: UpdateFederatedGraphResponse['deployment_errors'] = [];),
importing or referencing UpdateFederatedGraphResponse as needed so the
initialized empty arrays preserve the correct typed element shape instead of
any.

controlplane/test/override.test.ts-128-129 (1)

128-129: ⚠️ Potential issue | 🟡 Minor

Avoid casting to any when types are structurally compatible.

The as any cast on checkResp.breakingChanges bypasses type checking. While SchemaChange[] is structurally compatible with OverrideChange[] (both provide the required changeType and path fields), explicitly casting to any violates the TypeScript guidelines. Use a specific type cast (as OverrideChange[]) or create a proper conversion function instead to maintain type safety.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/test/override.test.ts` around lines 128 - 129, Replace the
unsafe any cast on checkResp.breakingChanges: instead of
"checkResp.breakingChanges as any" cast it to the correct type or convert items
to the expected shape; e.g., use "checkResp.breakingChanges as OverrideChange[]"
if types are truly compatible, or map checkResp.breakingChanges to an array of
OverrideChange objects (preserving changeType and path) before assigning to the
changes field so type safety is preserved; update the assignment that sets
changes to ensure it uses OverrideChange[] rather than any.

controlplane/src/core/bufservices/federated-graph/getRouters.ts-54-54 (1)

54-54: ⚠️ Potential issue | 🟡 Minor

Replace any[] with properly typed Router array.

Using any[] skips compiler checks and allows protobuf field drift to go unnoticed. The pushed objects match the Router type structure exactly. Use MessageInitShape<typeof RouterSchema>[] to maintain type safety for initialization shapes:

+import { MessageInitShape } from '@bufbuild/protobuf';
-import { GetRoutersRequest, GetRoutersResponse, Router } from '@wundergraph/cosmo-connect/dist/platform/v1/platform_pb';
+import { GetRoutersRequest, GetRoutersResponse, RouterSchema } from '@wundergraph/cosmo-connect/dist/platform/v1/platform_pb';
...
-    const routers: any[] = [];
+    const routers: MessageInitShape<typeof RouterSchema>[] = [];

This pattern is established in the codebase (e.g., shared/src/router-config/builder.ts) and follows the TypeScript guideline to avoid any types.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/federated-graph/getRouters.ts` at line 54,
Replace the loose any[] typing for the local variable routers with the
protobuf-initialization shape type so the compiler validates fields: change the
declaration of routers (in getRouters / getRouters.ts) to use
MessageInitShape<typeof RouterSchema>[]; add/import MessageInitShape and
RouterSchema if missing, and ensure the objects you push into routers conform to
that initialization shape (the pushed objects already match Router structure).

studio/src/components/notifications/components.tsx-2-3 (1)

2-3: ⚠️ Potential issue | 🟡 Minor

Split EventMeta into a type-only import to clarify intent and follow TypeScript best practices.

EventMeta is used only in type positions (line 17 as a type alias, line 96 as a type property access). Importing it with import type makes this explicit and improves code clarity.

Suggested fix

-import { EventMeta, EventMetaSchema, GraphSchemaUpdatedMetaSchema, ProposalStateUpdatedMetaSchema, OrganizationEventName } from '@wundergraph/cosmo-connect/dist/notifications/events_pb';
+import type { EventMeta } from '@wundergraph/cosmo-connect/dist/notifications/events_pb';
+import { EventMetaSchema, GraphSchemaUpdatedMetaSchema, ProposalStateUpdatedMetaSchema, OrganizationEventName } from '@wundergraph/cosmo-connect/dist/notifications/events_pb';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@studio/src/components/notifications/components.tsx` around lines 2 - 3,
Update the import so EventMeta is imported as a type-only import while keeping
the runtime schema/enum imports as value imports: change the combined import
from '@wundergraph/cosmo-connect/dist/notifications/events_pb' to two imports
where EventMeta is imported with "import type { EventMeta }" and the rest
(EventMetaSchema, GraphSchemaUpdatedMetaSchema, ProposalStateUpdatedMetaSchema,
OrganizationEventName) remain in a normal import; adjust any references to
EventMeta (type alias at line ~17 and type property access at line ~96)
accordingly but do not change runtime usages of the other symbols.

controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts-112-114 (1)

112-114: ⚠️ Potential issue | 🟡 Minor

Use the imported CompositionError, DeploymentError, and CompositionWarning types instead of any[].

The types are already imported but unused for typing these arrays. Replace the any[] annotations on lines 112-114 with the specific protobuf message types:

♻️ Suggested refactor

-    const compositionErrors: any[] = [];
-    const deploymentErrors: any[] = [];
-    const compositionWarnings: any[] = [];
+    const compositionErrors: CompositionError[] = [];
+    const deploymentErrors: DeploymentError[] = [];
+    const compositionWarnings: CompositionWarning[] = [];

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts` around
lines 112 - 114, Replace the loose any[] annotations with the specific protobuf
message types: change compositionErrors: any[] to compositionErrors:
CompositionError[], deploymentErrors: any[] to deploymentErrors:
DeploymentError[], and compositionWarnings: any[] to compositionWarnings:
CompositionWarning[] (these types are already imported), ensuring the variables
in deleteFeatureFlag.ts use the correct typed arrays.

controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts-55-55 (1)

55-55: ⚠️ Potential issue | 🟡 Minor

Replace any[] with specific type to preserve compile-time validation.

The requestSeriesList accumulator feeds graphs[].requestSeries directly in the response. Using any[] hides type mismatches between the analytics rows and the expected response shape.

♻️ Suggested typing

-    const requestSeriesList: Record<string, any[]> = {};
+    const requestSeriesList: Record<
+      string,
+      Awaited<ReturnType<AnalyticsDashboardViewRepository['getRequestSeries']>>
+    > = {};

Per coding guidelines: "Avoid any type in TypeScript; use specific types or generics".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts` at
line 55, The accumulator requestSeriesList is typed as Record<string, any[]>
which hides mismatches; change its type from any[] to a concrete array type
(e.g. define an interface like RequestSeriesItem or reuse the existing
RequestSeriesRow/RequestSeries type used by graphs[].requestSeries) and declare
requestSeriesList as Record<string, RequestSeriesItem[]> so the compiler
validates rows produced by the analytics query and the assignment to
graphs[].requestSeries; update any helper functions or mappings that push into
requestSeriesList (refer to requestSeriesList and graphs[].requestSeries in
getFederatedGraphs/getFederatedGraphs.ts) to satisfy the new shape.

controlplane/src/core/bufservices/analytics/getOperations.ts-10-15 (1)

10-15: ⚠️ Potential issue | 🟡 Minor

ESLint camelcase rule conflicts with protobuf-generated identifiers.

The pipeline is failing because ESLint's camelcase rule flags the underscore-delimited names (GetOperationsResponse_OperationSchema, GetOperationsResponse_OperationType, GetOperationsResponse_Operation). These are generated by protoc-gen-es from the proto schema and cannot be renamed.

You'll need to suppress the lint error for these imports. Consider one of:

1. Add an inline disable comment:

 import {
   AnalyticsFilterSchema,
   AnalyticsViewFilterOperator,
   GetOperationsRequest,
   GetOperationsResponse,
+  // eslint-disable-next-line camelcase
   GetOperationsResponse_OperationSchema,
+  // eslint-disable-next-line camelcase
   GetOperationsResponse_OperationType,
   OperationsFetchBasedOn,
   SortDirection,
   type AnalyticsFilter,
+  // eslint-disable-next-line camelcase
   type GetOperationsResponse_Operation,
 } from '@wundergraph/cosmo-connect/dist/platform/v1/platform_pb';

2. Or configure ESLint to allow this pattern globally for *_pb imports.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/analytics/getOperations.ts` around lines 10
- 15, The ESLint camelcase violations come from protobuf-generated identifiers
(GetOperationsResponse_OperationSchema, GetOperationsResponse_OperationType,
GetOperationsResponse_Operation) in the import list; suppress the lint rule
rather than renaming generated symbols by adding an inline disable comment
immediately above the import (e.g. /* eslint-disable-next-line camelcase */) or
update ESLint config to allow this pattern for generated protobuf imports (e.g.
allow identifiers matching /GetOperationsResponse_/ or *_pb), ensuring the
suppression targets only these import lines and references the exact identifiers
named above.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3d2ef0de-1369-44b5-8ed2-5a89bd2808d9

📥 Commits

Reviewing files that changed from the base of the PR and between 63db070 and 387be9e.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (299)

• buf.ts.gen.yaml
• cli/package.json
• cli/src/commands/graph/federated-graph/utils.ts
• cli/src/commands/mcp/tools/get-subgraphs.ts
• cli/src/commands/operations/commands/push.ts
• cli/src/commands/proposal/utils.ts
• cli/src/commands/router/commands/compose.ts
• cli/src/commands/subgraph/commands/check.ts
• cli/src/commands/subgraph/commands/fetch.ts
• cli/src/commands/subgraph/commands/publish.ts
• cli/src/core/client/client.ts
• cli/src/core/types/types.ts
• cli/src/github.ts
• cli/src/handle-composition-result.ts
• cli/src/handle-proposal-result.ts
• cli/src/json-check-schema-output-builder.ts
• cli/test/check-federated-graph.test.ts
• cli/test/check-schema.test.ts
• cli/test/create-subgraph.test.ts
• cli/test/fetch-schema.test.ts
• cli/test/graph/utils.ts
• cli/test/grpc-service.test.ts
• cli/test/json-check-schema-output-builder.test.ts
• cli/test/parse-operations.test.ts
• cli/test/publish-schema.test.ts
• composition-go/index.global.js
• composition-go/shim/package.json
• composition-go/shim/src/index.ts
• connect/package.json
• connect/src/wg/cosmo/common/common_pb.ts
• connect/src/wg/cosmo/node/v1/node-NodeService_connectquery.ts
• connect/src/wg/cosmo/node/v1/node_connect.ts
• connect/src/wg/cosmo/node/v1/node_pb.ts
• connect/src/wg/cosmo/notifications/events_pb.ts
• connect/src/wg/cosmo/platform/v1/platform-PlatformService_connectquery.ts
• connect/src/wg/cosmo/platform/v1/platform_connect.ts
• connect/src/wg/cosmo/platform/v1/platform_pb.ts
• controlplane/package.json
• controlplane/src/core/bufservices/NodeService.ts
• controlplane/src/core/bufservices/PlatformService.ts
• controlplane/src/core/bufservices/analytics/getAnalyticsView.ts
• controlplane/src/core/bufservices/analytics/getDashboardAnalyticsView.ts
• controlplane/src/core/bufservices/analytics/getFieldUsage.ts
• controlplane/src/core/bufservices/analytics/getGraphMetrics.ts
• controlplane/src/core/bufservices/analytics/getMetricsErrorRate.ts
• controlplane/src/core/bufservices/analytics/getOperationClients.ts
• controlplane/src/core/bufservices/analytics/getOperationContent.ts
• controlplane/src/core/bufservices/analytics/getOperationDeprecatedFields.ts
• controlplane/src/core/bufservices/analytics/getOperations.ts
• controlplane/src/core/bufservices/analytics/getOrganizationRequestsCount.ts
• controlplane/src/core/bufservices/analytics/getSubgraphMetrics.ts
• controlplane/src/core/bufservices/analytics/getSubgraphMetricsErrorRate.ts
• controlplane/src/core/bufservices/analytics/getTrace.ts
• controlplane/src/core/bufservices/api-key/createAPIKey.ts
• controlplane/src/core/bufservices/api-key/deleteAPIKey.ts
• controlplane/src/core/bufservices/api-key/getAPIKeys.ts
• controlplane/src/core/bufservices/api-key/updateAPIKey.ts
• controlplane/src/core/bufservices/api-key/verifyAPIKeyGraphAccess.ts
• controlplane/src/core/bufservices/billing/createBillingPortalSession.ts
• controlplane/src/core/bufservices/billing/createCheckoutSession.ts
• controlplane/src/core/bufservices/billing/getBillingPlans.ts
• controlplane/src/core/bufservices/billing/upgradePlan.ts
• controlplane/src/core/bufservices/cache-warmer/computeCacheWarmerOperations.ts
• controlplane/src/core/bufservices/cache-warmer/configureCacheWarmer.ts
• controlplane/src/core/bufservices/cache-warmer/deleteCacheWarmerOperation.ts
• controlplane/src/core/bufservices/cache-warmer/getCacheWarmerConfig.ts
• controlplane/src/core/bufservices/cache-warmer/getCacheWarmerOperations.ts
• controlplane/src/core/bufservices/cache-warmer/pushCacheWarmerOperation.ts
• controlplane/src/core/bufservices/check-extensions/configureSubgraphCheckExtensions.ts
• controlplane/src/core/bufservices/check-extensions/getSubgraphCheckExtensionsConfig.ts
• controlplane/src/core/bufservices/check/createIgnoreOverridesForAllOperations.ts
• controlplane/src/core/bufservices/check/createOperationIgnoreAllOverride.ts
• controlplane/src/core/bufservices/check/createOperationOverrides.ts
• controlplane/src/core/bufservices/check/forceCheckSuccess.ts
• controlplane/src/core/bufservices/check/getAllOverrides.ts
• controlplane/src/core/bufservices/check/getCheckOperations.ts
• controlplane/src/core/bufservices/check/getCheckSummary.ts
• controlplane/src/core/bufservices/check/getChecksByFederatedGraphName.ts
• controlplane/src/core/bufservices/check/getNamespaceChecksConfig.ts
• controlplane/src/core/bufservices/check/getOperationOverrides.ts
• controlplane/src/core/bufservices/check/getProposedSchemaOfCheckedSubgraph.ts
• controlplane/src/core/bufservices/check/isGitHubAppInstalled.ts
• controlplane/src/core/bufservices/check/removeOperationIgnoreAllOverride.ts
• controlplane/src/core/bufservices/check/removeOperationOverrides.ts
• controlplane/src/core/bufservices/check/toggleChangeOverridesForAllOperations.ts
• controlplane/src/core/bufservices/check/updateNamespaceChecksConfig.ts
• controlplane/src/core/bufservices/contract/createContract.ts
• controlplane/src/core/bufservices/contract/updateContract.ts
• controlplane/src/core/bufservices/feature-flag/createFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/enableFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlagByName.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlags.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlagsByFederatedGraph.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphs.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphsByFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/updateFeatureFlag.ts
• controlplane/src/core/bufservices/federated-graph/checkFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraphToken.ts
• controlplane/src/core/bufservices/federated-graph/deleteFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/deleteRouterToken.ts
• controlplane/src/core/bufservices/federated-graph/generateRouterToken.ts
• controlplane/src/core/bufservices/federated-graph/getClientsFromAnalytics.ts
• controlplane/src/core/bufservices/federated-graph/getCompositionDetails.ts
• controlplane/src/core/bufservices/federated-graph/getCompositions.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphChangelog.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphSDLByName.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphsBySubgraphLabels.ts
• controlplane/src/core/bufservices/federated-graph/getRouterTokens.ts
• controlplane/src/core/bufservices/federated-graph/getRouters.ts
• controlplane/src/core/bufservices/federated-graph/migrateFromApollo.ts
• controlplane/src/core/bufservices/federated-graph/moveFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/updateFederatedGraph.ts
• controlplane/src/core/bufservices/graph/recomposeGraph.ts
• controlplane/src/core/bufservices/graph/setGraphRouterCompatibilityVersion.ts
• controlplane/src/core/bufservices/linting/configureNamespaceGraphPruningConfig.ts
• controlplane/src/core/bufservices/linting/configureNamespaceLintConfig.ts
• controlplane/src/core/bufservices/linting/enableGraphPruning.ts
• controlplane/src/core/bufservices/linting/enableLintingForTheNamespace.ts
• controlplane/src/core/bufservices/linting/getNamespaceGraphPruningConfig.ts
• controlplane/src/core/bufservices/linting/getNamespaceLintConfig.ts
• controlplane/src/core/bufservices/monograph/createMonograph.ts
• controlplane/src/core/bufservices/monograph/deleteMonograph.ts
• controlplane/src/core/bufservices/monograph/migrateMonograph.ts
• controlplane/src/core/bufservices/monograph/moveMonograph.ts
• controlplane/src/core/bufservices/monograph/publishMonograph.ts
• controlplane/src/core/bufservices/monograph/updateMonograph.ts
• controlplane/src/core/bufservices/namespace/createNamespace.ts
• controlplane/src/core/bufservices/namespace/deleteNamespace.ts
• controlplane/src/core/bufservices/namespace/getNamespace.ts
• controlplane/src/core/bufservices/namespace/getNamespaces.ts
• controlplane/src/core/bufservices/namespace/renameNamespace.ts
• controlplane/src/core/bufservices/notification/createIntegration.ts
• controlplane/src/core/bufservices/notification/createOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/notification/deleteIntegration.ts
• controlplane/src/core/bufservices/notification/deleteOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/notification/getOrganizationIntegrations.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookConfigs.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookHistory.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookMeta.ts
• controlplane/src/core/bufservices/notification/getWebhookDeliveryDetails.ts
• controlplane/src/core/bufservices/notification/redeliverWebhook.ts
• controlplane/src/core/bufservices/notification/updateIntegrationConfig.ts
• controlplane/src/core/bufservices/notification/updateOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/organization/createOrganization.ts
• controlplane/src/core/bufservices/organization/createOrganizationGroup.ts
• controlplane/src/core/bufservices/organization/deleteOrganization.ts
• controlplane/src/core/bufservices/organization/deleteOrganizationGroup.ts
• controlplane/src/core/bufservices/organization/getAuditLogs.ts
• controlplane/src/core/bufservices/organization/getOrganizationBySlug.ts
• controlplane/src/core/bufservices/organization/getOrganizationGroupMembers.ts
• controlplane/src/core/bufservices/organization/getOrganizationGroups.ts
• controlplane/src/core/bufservices/organization/getOrganizationMembers.ts
• controlplane/src/core/bufservices/organization/getPendingOrganizationMembers.ts
• controlplane/src/core/bufservices/organization/isMemberLimitReached.ts
• controlplane/src/core/bufservices/organization/leaveOrganization.ts
• controlplane/src/core/bufservices/organization/listOrganizations.ts
• controlplane/src/core/bufservices/organization/restoreOrganization.ts
• controlplane/src/core/bufservices/organization/updateFeatureSettings.ts
• controlplane/src/core/bufservices/organization/updateOrganizationDetails.ts
• controlplane/src/core/bufservices/organization/updateOrganizationGroup.ts
• controlplane/src/core/bufservices/organization/whoAmI.ts
• controlplane/src/core/bufservices/persisted-operation/check-persisted-operation-traffic.ts
• controlplane/src/core/bufservices/persisted-operation/deletePersistedOperation.ts
• controlplane/src/core/bufservices/persisted-operation/getClients.ts
• controlplane/src/core/bufservices/persisted-operation/getPersistedOperations.ts
• controlplane/src/core/bufservices/persisted-operation/publishPersistedOperations.ts
• controlplane/src/core/bufservices/playground/createPlaygroundScript.ts
• controlplane/src/core/bufservices/playground/deletePlaygroundScript.ts
• controlplane/src/core/bufservices/playground/getPlaygroundScripts.ts
• controlplane/src/core/bufservices/playground/updatePlaygroundScript.ts
• controlplane/src/core/bufservices/plugin/validateAndFetchPluginData.ts
• controlplane/src/core/bufservices/proposal/configureNamespaceProposalConfig.ts
• controlplane/src/core/bufservices/proposal/createProposal.ts
• controlplane/src/core/bufservices/proposal/enableProposalsForNamespace.ts
• controlplane/src/core/bufservices/proposal/getNamespaceProposalConfig.ts
• controlplane/src/core/bufservices/proposal/getProposal.ts
• controlplane/src/core/bufservices/proposal/getProposalChecks.ts
• controlplane/src/core/bufservices/proposal/getProposalsByFederatedGraph.ts
• controlplane/src/core/bufservices/proposal/updateProposal.ts
• controlplane/src/core/bufservices/router/listRouterCompatibilityVersions.ts
• controlplane/src/core/bufservices/schema-version/getChangelogBySchemaVersion.ts
• controlplane/src/core/bufservices/schema-version/getSdlBySchemaVersion.ts
• controlplane/src/core/bufservices/sso/createOIDCProvider.ts
• controlplane/src/core/bufservices/sso/deleteOIDCProvider.ts
• controlplane/src/core/bufservices/sso/getOIDCProvider.ts
• controlplane/src/core/bufservices/sso/updateIDPMappers.ts
• controlplane/src/core/bufservices/subgraph/addReadme.ts
• controlplane/src/core/bufservices/subgraph/checkSubgraphSchema.ts
• controlplane/src/core/bufservices/subgraph/createFederatedSubgraph.ts
• controlplane/src/core/bufservices/subgraph/deleteFederatedSubgraph.ts
• controlplane/src/core/bufservices/subgraph/fixSubgraphSchema.ts
• controlplane/src/core/bufservices/subgraph/getLatestSubgraphSDL.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphById.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphByName.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphMembers.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphSDLFromLatestComposition.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphs.ts
• controlplane/src/core/bufservices/subgraph/linkSubgraph.ts
• controlplane/src/core/bufservices/subgraph/moveSubgraph.ts
• controlplane/src/core/bufservices/subgraph/publishFederatedSubgraph.ts
• controlplane/src/core/bufservices/subgraph/unlinkSubgraph.ts
• controlplane/src/core/bufservices/subgraph/updateSubgraph.ts
• controlplane/src/core/bufservices/user/acceptOrDeclineInvitation.ts
• controlplane/src/core/bufservices/user/deleteUser.ts
• controlplane/src/core/bufservices/user/getInvitations.ts
• controlplane/src/core/bufservices/user/getUserAccessiblePermissions.ts
• controlplane/src/core/bufservices/user/getUserAccessibleResources.ts
• controlplane/src/core/bufservices/user/initializeCosmoUser.ts
• controlplane/src/core/bufservices/user/inviteUser.ts
• controlplane/src/core/bufservices/user/removeInvitation.ts
• controlplane/src/core/bufservices/user/removeOrganizationMember.ts
• controlplane/src/core/bufservices/user/updateOrgMemberGroup.ts
• controlplane/src/core/bufservices/workspace/getWorkspace.ts
• controlplane/src/core/composition/composeGraphs.pool.ts
• controlplane/src/core/composition/composeGraphs.types.ts
• controlplane/src/core/composition/composeGraphs.worker.ts
• controlplane/src/core/composition/composer.ts
• controlplane/src/core/errors/errors.ts
• controlplane/src/core/repositories/ApiKeyRepository.ts
• controlplane/src/core/repositories/CacheWarmerRepository.ts
• controlplane/src/core/repositories/FederatedGraphRepository.ts
• controlplane/src/core/repositories/GitHubRepository.ts
• controlplane/src/core/repositories/OperationsRepository.ts
• controlplane/src/core/repositories/OrganizationRepository.ts
• controlplane/src/core/repositories/SchemaCheckRepository.ts
• controlplane/src/core/repositories/SubgraphRepository.ts
• controlplane/src/core/repositories/analytics/AnalyticsDashboardViewRepository.ts
• controlplane/src/core/repositories/analytics/AnalyticsRequestViewRepository.ts
• controlplane/src/core/repositories/analytics/TraceRepository.ts
• controlplane/src/core/repositories/analytics/UsageRepository.ts
• controlplane/src/core/repositories/analytics/util.ts
• controlplane/src/core/routes.ts
• controlplane/src/core/util.ts
• controlplane/src/core/webhooks/OrganizationWebhookService.ts
• controlplane/src/core/webhooks/PlatformWebhookService.ts
• controlplane/src/core/workers/CacheWarmerWorker.ts
• controlplane/src/types/index.ts
• controlplane/test/authentication.test.ts
• controlplane/test/check-subgraph-schema.test.ts
• controlplane/test/compose-federationv1-graphs.test.ts
• controlplane/test/compose-federationv2-graphs.test.ts
• controlplane/test/graph-pruning.test.ts
• controlplane/test/integrations.test.ts
• controlplane/test/oidc-provider.test.ts
• controlplane/test/organization-groups.test.ts
• controlplane/test/override.test.ts
• controlplane/test/proposal/proposal-webhooks.test.ts
• controlplane/test/restore-organization.test.ts
• controlplane/test/scim.test.ts
• controlplane/test/subgraph-check-extensions.test.ts
• controlplane/test/subgraph/subgraph.test.ts
• controlplane/test/test-util.ts
• demo/pkg/subgraphs/courses/src/plugin.test.ts
• demo/pkg/subgraphs/courses/src/plugin.ts
• docs/superpowers/plans/2026-03-20-connect-v2-upgrade.md
• graphqlmetrics/core/metrics_service_test.go
• package.json
• protographic/package.json
• protographic/src/index.ts
• protographic/src/required-fields-visitor.ts
• protographic/src/sdl-to-mapping-visitor.ts
• protographic/tests/sdl-to-mapping/01-basics.test.ts
• protographic/tests/sdl-to-mapping/02-complex-types.test.ts
• protographic/tests/sdl-to-mapping/03-federation.test.ts
• protographic/tests/sdl-to-mapping/04-field-resolvers.test.ts
• shared/package.json
• shared/src/router-config/builder.ts
• shared/src/router-config/graphql-configuration.ts
• shared/src/router-config/utils.ts
• shared/test/required-field.test.ts
• shared/test/router.config.test.ts
• shared/test/subscription-filter.test.ts
• studio/package.json
• studio/src/components/app-provider.tsx
• studio/src/components/check-extensions/check-extensions-config.tsx
• studio/src/components/checks/changes-table.tsx
• studio/src/components/checks/operations.tsx
• studio/src/components/checks/override.tsx
• studio/src/components/create-graph.tsx
• studio/src/components/dashboard/workspace-command-wrapper.tsx
• studio/src/components/dashboard/workspace-provider.tsx
• studio/src/components/lint-policy/graph-pruning-config.tsx
• studio/src/components/lint-policy/linter-config.tsx
• studio/src/components/member-groups/group-resource-selector.tsx
• studio/src/components/member-groups/group-rule-builder.tsx
• studio/src/components/member-groups/group-sheet.tsx
• studio/src/components/notifications/components.tsx
• studio/src/components/playground/custom-scripts.tsx
• studio/src/components/settings/restore-organization.tsx
• studio/src/pages/[organizationSlug]/[namespace]/graph/[slug]/analytics/index.tsx
• studio/src/pages/[organizationSlug]/[namespace]/graph/[slug]/operations.tsx
• studio/src/pages/[organizationSlug]/[namespace]/graph/[slug]/playground.tsx
• studio/src/pages/[organizationSlug]/[namespace]/subgraph/[subgraphSlug]/analytics/index.tsx
• studio/src/pages/[organizationSlug]/groups.tsx

💤 Files with no reviewable changes (3)

• buf.ts.gen.yaml
• connect/src/wg/cosmo/node/v1/node_connect.ts
• connect/src/wg/cosmo/platform/v1/platform_connect.ts

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

How to import StringValue Well-Known Types in @bufbuild/protobuf v2?

💡 Result:

In @bufbuild/protobuf v2 (part of Protobuf-ES v2), Well-Known Types like google.protobuf.StringValue are pre-generated and bundled in the runtime library @bufbuild/protobuf. They do not require separate imports or generation when referenced in your .proto files; the code generator automatically handles them via relative imports from your generated code. To use StringValue: 1. In your .proto file, import the wrappers.proto: import "google/protobuf/wrappers.proto"; message MyMessage { google.protobuf.StringValue wrapped_string = 1; } 2. Generate code with protoc-gen-es (via buf generate or protoc): npx buf generate or protoc --es_out=gen --es_opt=target=ts your.proto 3. In generated code, fields using StringValue are "unboxed" to optional string for convenience: wrappedString?: string; The generated code imports the necessary WKT symbols automatically (e.g., from internal paths in @bufbuild/protobuf). 4. Use with the schema-based API: import { create } from "@bufbuild/protobuf"; import { MyMessage, MyMessageSchema } from "./gen/your_pb.js"; const msg = create(MyMessageSchema, { wrappedString: "hello", // Sets the wrapped value }); Well-Known Types ship pre-compiled in @bufbuild/protobuf, so no explicit user import like import { StringValue } from "@bufbuild/protobuf"; is needed unless directly instantiating the wrapper message outside generated code (rare, as wrappers are typically unboxed). For Timestamp and others, generation works similarly without extra steps.

Citations:

• 1: https://github.com/bufbuild/protobuf-es/blob/main/MANUAL.md
• 2: Generated code not importing from buf for a dependency bufbuild/protobuf-es#947
• 3: https://buf.build/blog/protobuf-es-v2
• 4: https://github.com/bufbuild/protobuf-es
• 5: https://github.com/bufbuild/protobuf-es/blob/main/docs/generated_code.md
• 6: https://www.npmjs.com/package/@bufbuild/protobuf

---

🏁 Script executed:

# Find package.json files to determine dependencies
fd -t f "package.json" | head -10

Repository: wundergraph/cosmo

Length of output: 388

---

🏁 Script executed:

# Check the plugin.ts file to understand the context
cat -n demo/pkg/subgraphs/courses/src/plugin.ts | head -100

Repository: wundergraph/cosmo

Length of output: 3414

---

🏁 Script executed:

# Search for other imports from google-protobuf or `@bufbuild/protobuf`
rg "(google-protobuf|@bufbuild/protobuf)" --type ts --type tsx -A 2 -B 2

Repository: wundergraph/cosmo

Length of output: 88

---

🏁 Script executed:

# Find the root package.json and check dependencies
fd -t f "package.json" -x grep -l "bufbuild\|google-protobuf" {} \; | head -5

Repository: wundergraph/cosmo

Length of output: 175

---

🏁 Script executed:

# Check if StringValueSchema is actually used in plugin.ts
rg "StringValueSchema" demo/pkg/subgraphs/courses/src/plugin.ts -B 2 -A 5

Repository: wundergraph/cosmo

Length of output: 964

---

🏁 Script executed:

# Search for all imports from google-protobuf or `@bufbuild/protobuf` across the repo
rg "from ['\"](`@bufbuild/protobuf`|google-protobuf)" -t ts

Repository: wundergraph/cosmo

Length of output: 7692

---

🏁 Script executed:

# Check the main root package.json for dependency versions
cat -n package.json | grep -A 20 "dependencies\|devDependencies"

Repository: wundergraph/cosmo

Length of output: 997

---

🏁 Script executed:

# Check what's exported from the generated service_pb files
grep -n "StringValue\|wrappers" demo/pkg/subgraphs/courses/generated/service_pb.d.ts | head -20

Repository: wundergraph/cosmo

Length of output: 626

---

🏁 Script executed:

# Check if StringValueSchema might be available in the generated files
rg "StringValueSchema" demo/pkg/subgraphs/courses/generated/

Repository: wundergraph/cosmo

Length of output: 43

---

🏁 Script executed:

# Look for how other files in the codebase use Well-Known Types from `@bufbuild/protobuf`
rg "StringValue|wrappers" connect/src/ --type ts | head -20

Repository: wundergraph/cosmo

Length of output: 43

---

🏁 Script executed:

# Check the actual proto file to understand the field definitions
fd -t f "*.proto" demo/pkg/subgraphs/courses/

Repository: wundergraph/cosmo

Length of output: 347

---

🏁 Script executed:

# Find proto files in the courses directory
fd -t f ".proto" demo/pkg/subgraphs/courses/

Repository: wundergraph/cosmo

Length of output: 239

---

🏁 Script executed:

# Search for how StringValue is used in connect (codegen v2 style)
rg "StringValue" connect/src/ -t ts -B 2 -A 2

Repository: wundergraph/cosmo

Length of output: 43

---

🏁 Script executed:

# Check the actual .proto file content
cat demo/pkg/subgraphs/courses/src/service.proto 2>/dev/null || cat demo/pkg/subgraphs/courses/service.proto 2>/dev/null || find demo/pkg/subgraphs/courses -name "*.proto" -exec cat {} \;

Repository: wundergraph/cosmo

Length of output: 3835

---

🏁 Script executed:

# Check if there's a buf.gen.yaml or similar configuration for proto generation
fd -t f "buf.gen.yaml" demo/pkg/subgraphs/courses/

Repository: wundergraph/cosmo

Length of output: 43

---

🏁 Script executed:

# Look for generation scripts or instructions
fd -t f "generate\|Makefile\|package.json" demo/pkg/subgraphs/courses/ | xargs grep -l "buf generate\|protoc" 2>/dev/null | head -5

Repository: wundergraph/cosmo

Length of output: 43

---

🏁 Script executed:

# Check the package.json in the courses directory for generation scripts
cat demo/pkg/subgraphs/courses/package.json 2>/dev/null || cat demo/pkg/subgraphs/courses/src/../package.json

Repository: wundergraph/cosmo

Length of output: 952

---

Migrate courses subgraph proto generation to @bufbuild/protobuf v2 for consistency.

The courses subgraph uses the legacy google-protobuf toolchain (grpc-tools, protoc-gen-js) while the rest of the codebase uses @bufbuild/protobuf. This creates a mixed dependency where code imports create() from @bufbuild/protobuf but uses schemas from google-protobuf, causing the need for StringValueSchema.

With @bufbuild/protoc-gen-es, Well-Known Types like StringValue are "unboxed" to optional fields in generated code, eliminating the need for explicit schema imports. Update the courses subgraph's package.json to use @bufbuild/protoc-gen-es and regenerate the proto files for alignment with the rest of the codebase.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@demo/pkg/subgraphs/courses/src/plugin.ts` at line 49, The import of
StringValueSchema from google-protobuf is a symptom of using the legacy
toolchain; switch the courses subgraph to `@bufbuild/protoc-gen-es` in
package.json, re-run proto generation so generated files target
`@bufbuild/protobuf` v2 (which unboxes Well-Known Types), then remove the explicit
import of StringValueSchema and update usages to the `@bufbuild/protobuf-style`
optional fields (and existing create() calls) in plugin.ts and regenerated files
so everything consistently uses `@bufbuild/protobuf` v2.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

What is the createConnectQueryKey API signature in @connectrpc/connect-query v2?

💡 Result:

The createConnectQueryKey function in @connectrpc/connect-query v2 (re-exported from @connectrpc/connect-query-core) creates a TanStack Query key for Connect RPC methods. Its signature, inferred from usage examples in the official GitHub repository README and issue discussions for v2.2.0, is: ts createConnectQueryKey({ schema: DescMethodUnary<I, O>, transport: Transport, input: MessageInitShape | undefined, cardinality: 'finite' | 'infinite', }) It returns a ConnectQueryKey, which is a branded readonly array: ts type ConnectQueryKey = readonly [ 'connect-query', { transport?: string; serviceName: string; methodName?: string; input?: Record<string, unknown> | 'skipped'; cardinality?: 'infinite' | 'finite'; } ]; This structure distinguishes Connect query keys and includes the service/method details, transport key, serialized input, and cardinality for finite/unary vs. infinite/server-streaming queries. Examples from the repo show this exact object passed to generate keys matching the ConnectQueryKey type. Note: v1 had a simpler signature using method descriptor picks, but v2 uses schema/transport for better type safety with Connect-ES v2 types.

Citations:

• 1: Can we add createMutationOptions()? connectrpc/connect-query-es#550
• 2: https://registry.npmjs.org/%40connectrpc%2Fconnect-query
• 3: https://registry.npmjs.org/%40connectrpc%2Fconnect-query-core
• 4: https://github.com/connectrpc/connect-query-es
• 5: https://connectrpc.com/docs/query/getting-started/
• 6: https://app.unpkg.com/@connectrpc/connect-query@1.4.1/files/dist/esm/connect-query-key.d.ts

---

Add the missing transport parameter to createConnectQueryKey call.

The Connect Query v2 API signature requires a transport parameter, but the current code omits it. According to @connectrpc/connect-query v2 documentation, createConnectQueryKey must include { schema, transport, input, cardinality } as a single object argument. Update line 201-203 to include the required transport parameter for proper query key generation and cache invalidation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@studio/src/components/playground/custom-scripts.tsx` around lines 201 - 203,
The createConnectQueryKey call is missing the required transport option; update
the call to pass transport along with schema, input and cardinality. Locate the
createConnectQueryKey invocation (the call using getPlaygroundScripts and input:
{ type: script.type }) and add the transport parameter (the same transport
instance used for other Connect Query v2 calls in this module) so the object
argument becomes { schema: getPlaygroundScripts, transport, input: { type:
script.type }, cardinality: "finite" }.

[coderabbitai]

Actionable comments posted: 12

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (4)

controlplane/src/core/repositories/OrganizationRepository.ts (3)

747-765: ⚠️ Potential issue | 🟠 Major

Avoid using any to hide type mismatches; construct proper EventMeta instances or adjust the return type.

getWebhookMeta() declares return type Promise<EventMeta[]> but builds plain objects in an untyped any[] array (line 18), then hides the mismatch with a cast (line 92). This bypasses TypeScript's type checking at the protobuf boundary. Either construct actual EventMeta values using the generated schema, keep the return type as PlainMessage<EventMeta>[], or use a properly-typed intermediate structure—but avoid the any escape hatch.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/repositories/OrganizationRepository.ts` around lines
747 - 765, getWebhookMeta builds an untyped any[] (meta) and then casts to
EventMeta[], which hides type mismatches; fix by producing properly-typed
protobuf messages or adjusting the signature: either construct EventMeta
instances (or PlainMessage<EventMeta> objects) using the generated protobuf
constructors/types instead of pushing plain any objects into meta in
getWebhookMeta, or change the method return type to
Promise<PlainMessage<EventMeta>[]> (and propagate that change) so the code uses
the correct intermediate type; update references in the function to create
values matching EventMeta (or PlainMessage<EventMeta>) rather than using any.

---

1168-1176: ⚠️ Potential issue | 🟠 Major

Use IntegrationConfig type instead of any for both integration config objects.

Both branches use const config: any before assigning to integrationConfig, which bypasses type safety. A mismatched oneof case/value pair would compile successfully but fail at runtime. Use IntegrationConfig from the generated schema directly instead of widening to any.

Also applies to: lines 1224-1232

Per coding guidelines: "Avoid any type in TypeScript; use specific types or generics"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/repositories/OrganizationRepository.ts` around lines
1168 - 1176, Replace the loose "const config: any" with the generated
IntegrationConfig type and construct the object to match the oneof structure
exactly (e.g., for Slack use IntegrationType.SLACK, case:
'slackIntegrationConfig', value: { endpoint: slackIntegrationConfig.endpoint })
so the compiler checks the case/value pairing; do the same for the other branch
(lines 1224-1232) so both integration config objects are typed as
IntegrationConfig from the generated schema and assigned to integrationConfig
without using any.

---

1560-1568: ⚠️ Potential issue | 🟠 Major

Define a type for the transformed webhook delivery response shape.

The return type deliveries: any[] bypasses type checking for all callers. The data structure is explicitly transformed with mapped fields (createdBy, isRedelivery), JSON-stringified headers/body, and ISO-formatted timestamps—this is a distinct shape from the raw database entity. Create a dedicated DTO type instead:

type WebhookDeliveryHistoryItem = {
  id: string;
  organizationId: string;
  type: string;
  endpoint: string;
  eventName: string;
  payload: string;
  createdAt: string; // ISO string
  createdBy?: string;
  isRedelivery: boolean;
  requestHeaders: string; // JSON stringified
  responseHeaders?: string;
  responseStatusCode?: number;
  responseErrorCode?: string;
  responseBody?: string;
  errorMessage?: string;
  // ...other fields as needed
};

Then update the return type to Promise<{ deliveries: WebhookDeliveryHistoryItem[]; totalCount: number }>.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/repositories/OrganizationRepository.ts` around lines
1560 - 1568, The getWebhookHistory method currently returns deliveries: any[]
which disables type-checking for the transformed payload; define a specific DTO
type (e.g., WebhookDeliveryHistoryItem) describing the transformed shape (id,
organizationId, type, endpoint, eventName, payload, createdAt as ISO string,
createdBy?, isRedelivery, requestHeaders as JSON string, responseHeaders?,
responseStatusCode?, responseErrorCode?, responseBody?, errorMessage?, etc.) and
update the method signature to Promise<{ deliveries:
WebhookDeliveryHistoryItem[]; totalCount: number }>, then ensure the mapping
inside getWebhookHistory constructs objects that conform to
WebhookDeliveryHistoryItem so TS will validate the transformation.

controlplane/src/core/repositories/CacheWarmerRepository.ts (1)

514-524: ⚠️ Potential issue | 🟡 Minor

Move serialization into the existing try block.

Line 514 can throw before the catch is entered, so serialization failures would bypass the upload-failure log entirely. Wrapping Buffer.from(toJsonString(...)) with the existing try keeps serialization and upload failures observable in one place.

Suggested change

-    const cacheWarmerOperationsBytes = Buffer.from(
-      toJsonString(CacheWarmerOperationsSchema, cacheWarmerOperations),
-      'utf8',
-    );
     const path = `${organizationId}/${federatedGraphId}/cache_warmup/operations.json`;
     try {
+      const cacheWarmerOperationsBytes = Buffer.from(
+        toJsonString(CacheWarmerOperationsSchema, cacheWarmerOperations),
+        'utf8',
+      );
       await blobStorage.putObject<S3RouterConfigMetadata>({
         key: path,
         body: cacheWarmerOperationsBytes,
         contentType: 'application/json; charset=utf-8',
       });

As per coding guidelines, "Add proper error handling with try-catch blocks".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/repositories/CacheWarmerRepository.ts` around lines 514
- 524, The serialization call
Buffer.from(toJsonString(CacheWarmerOperationsSchema, cacheWarmerOperations),
'utf8') is outside the try/catch so any serialization error bypasses the
upload-failure handling; move the toJsonString + Buffer.from steps inside the
existing try block that surrounds blobStorage.putObject so both serialization
and upload errors are caught and logged together (update references to
cacheWarmerOperationsBytes, CacheWarmerOperationsSchema, toJsonString, path and
blobStorage.putObject accordingly).

♻️ Duplicate comments (2)

controlplane/src/core/bufservices/namespace/deleteNamespace.ts (1)

16-19: ⚠️ Potential issue | 🟡 Minor

Add an explicit return type to deleteNamespace.

At Line 16, the function return type is inferred. Please declare it explicitly as Promise<DeleteNamespaceResponse> for a clear handler contract.

Suggested change

-export function deleteNamespace(opts: RouterOptions, req: DeleteNamespaceRequest, ctx: HandlerContext) {
+export function deleteNamespace(
+  opts: RouterOptions,
+  req: DeleteNamespaceRequest,
+  ctx: HandlerContext,
+): Promise<DeleteNamespaceResponse> {

#!/bin/bash
# Verify that deleteNamespace has an explicit Promise<DeleteNamespaceResponse> return type
sed -n '14,24p' controlplane/src/core/bufservices/namespace/deleteNamespace.ts
rg -nP 'export function\s+deleteNamespace\s*\([^)]*\)\s*:\s*Promise<DeleteNamespaceResponse>' controlplane/src/core/bufservices/namespace/deleteNamespace.ts

As per coding guidelines, "Use explicit type annotations for function parameters and return types in TypeScript."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/namespace/deleteNamespace.ts` around lines
16 - 19, The function deleteNamespace currently relies on an inferred return
type; update its signature to explicitly declare the return type
Promise<DeleteNamespaceResponse> (e.g., export function deleteNamespace(opts:
RouterOptions, req: DeleteNamespaceRequest, ctx: HandlerContext):
Promise<DeleteNamespaceResponse>) so callers and the handler contract are
clear—adjust any related overloads or imports if necessary and ensure the
implementation (including the call to handleError) still returns a
Promise<DeleteNamespaceResponse>.

controlplane/src/core/bufservices/contract/updateContract.ts (1)

155-157: ⚠️ Potential issue | 🟠 Major

Replace any[] response accumulators with concrete response types.

Using any[] here weakens compile-time guarantees for values returned to clients.

♻️ Suggested fix

-    const compositionErrors: any[] = [];
-    const deploymentErrors: any[] = [];
-    const compositionWarnings: any[] = [];
+    const compositionErrors: UpdateContractResponse['compositionErrors'] = [];
+    const deploymentErrors: UpdateContractResponse['deploymentErrors'] = [];
+    const compositionWarnings: UpdateContractResponse['compositionWarnings'] = [];

As per coding guidelines, "Avoid any type in TypeScript; use specific types or generics".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/contract/updateContract.ts` around lines
155 - 157, The three accumulators compositionErrors, deploymentErrors, and
compositionWarnings are typed as any[]; replace them with concrete types (e.g.,
CompositionError[], DeploymentError[], CompositionWarning[] or appropriate
existing interfaces) by importing or declaring the correct interfaces and
updating all usages and the surrounding return/response types in updateContract
to match; ensure you update any function signatures or result objects that
include these arrays so the compiler enforces the correct shape and remove any
remaining casts to any.

🧹 Nitpick comments (16)

controlplane/src/core/bufservices/federated-graph/getCompositionDetails.ts (1)

14-17: Consider adding explicit return type annotation.

The function's return type is now inferred after removing PlainMessage wrapper. While the inference works correctly, adding an explicit return type annotation would align with the project's TypeScript guidelines and provide better documentation at call sites.

As per coding guidelines: "Use explicit type annotations for function parameters and return types in TypeScript".

♻️ Suggested change

-export function getCompositionDetails(opts: RouterOptions, req: GetCompositionDetailsRequest, ctx: HandlerContext) {
+export function getCompositionDetails(opts: RouterOptions, req: GetCompositionDetailsRequest, ctx: HandlerContext): Promise<GetCompositionDetailsResponse> {
   let logger = getLogger(ctx, opts.logger);
 
   return handleError(ctx, logger, async () => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/federated-graph/getCompositionDetails.ts`
around lines 14 - 17, getCompositionDetails currently relies on an inferred
return type after removing the PlainMessage wrapper; add an explicit return type
annotation for the function (e.g., the appropriate Promise<...> type or a
specific response type) to comply with the project's TypeScript guidelines and
improve documentation. Locate the function declaration for getCompositionDetails
and annotate its signature with the correct return type that matches the value
returned by the async handleError callback (using the types used in this file
such as RouterOptions, GetCompositionDetailsRequest, HandlerContext and the
actual response type produced by the handler).

controlplane/src/core/bufservices/subgraph/checkSubgraphSchema.ts (1)

32-35: Consider adding explicit return type annotation.

While removing PlainMessage wrapper is correct for the Connect v2 migration, the function now relies entirely on type inference. Per coding guidelines, explicit return types are preferred for function declarations in TypeScript.

Given this function has many return paths (~10 different return statements), an explicit return type would help catch shape mismatches at compile time.

That said, since this is part of a broader migration pattern across the codebase and TypeScript inference will work correctly, this is a minor suggestion.

💡 Possible explicit typing (optional)

-export function checkSubgraphSchema(opts: RouterOptions, req: CheckSubgraphSchemaRequest, ctx: HandlerContext) {
+export function checkSubgraphSchema(
+  opts: RouterOptions,
+  req: CheckSubgraphSchemaRequest,
+  ctx: HandlerContext,
+): ReturnType<typeof handleError<CheckSubgraphSchemaResponse>> {

Alternatively, if handleError returns a consistent wrapper type in Connect v2, that type could be used directly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/subgraph/checkSubgraphSchema.ts` around
lines 32 - 35, Add an explicit return type to the checkSubgraphSchema function
declaration (which currently takes RouterOptions, CheckSubgraphSchemaRequest and
HandlerContext) instead of relying on inference; determine the exact return type
by inspecting the handleError<T>() utility used in the body (or the concrete
response wrapper used elsewhere in the Connect v2 migration) and annotate the
function with that type so all ~10 return paths are checked by the compiler and
shape mismatches are caught at compile time.

controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts (1)

22-25: Consider adding explicit return type annotation.

The return type is now inferred after removing the PlainMessage<DeleteFeatureFlagResponse> wrapper. While type inference works, adding an explicit return type improves code documentation and catches mismatches at the function boundary.

As per coding guidelines: "Use explicit type annotations for function parameters and return types in TypeScript".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts` around
lines 22 - 25, Add an explicit return type to the deleteFeatureFlag function
signature (e.g. Promise<DeleteFeatureFlagResponse> or the appropriate
PlainMessage-wrapped variant your handler returns) so the function reads like:
export function deleteFeatureFlag(...): Promise<DeleteFeatureFlagResponse> { ...
}; ensure the type you choose matches the value returned inside the handleError
callback and import the DeleteFeatureFlagResponse type if not already imported.

controlplane/src/core/bufservices/check/getCheckSummary.ts (1)

25-28: Consider retaining explicit return type annotation for better readability.

The explicit return type annotation was removed as part of the v2 migration. While type inference will work correctly here, the coding guidelines recommend explicit return type annotations for TypeScript functions. Since this is a consistent migration pattern across the codebase, this is a low-priority suggestion.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/check/getCheckSummary.ts` around lines 25 -
28, Add an explicit return type annotation to the getCheckSummary function
signature (which currently takes RouterOptions, GetCheckSummaryRequest,
HandlerContext) to match the inferred return type from the async handler (for
example, Promise<GetCheckSummaryResponse> or the actual inferred type in your
codebase); update the function declaration for getCheckSummary to include that
explicit return type to follow the project's TypeScript style guidelines.

controlplane/src/core/bufservices/monograph/createMonograph.ts (1)

26-29: Restore an explicit return type on this exported handler.

Line 26 and Line 29 now rely on inference, but this repo’s TS guideline requires explicit return types for functions. Please annotate the handler return explicitly and keep the async callback typed as needed.

Proposed patch

-export function createMonograph(opts: RouterOptions, req: CreateMonographRequest, ctx: HandlerContext) {
+export function createMonograph(
+  opts: RouterOptions,
+  req: CreateMonographRequest,
+  ctx: HandlerContext,
+): Promise<CreateMonographResponse> {
   let logger = getLogger(ctx, opts.logger);

-  return handleError(ctx, logger, async () => {
+  return handleError(ctx, logger, async (): Promise<CreateMonographResponse> => {

As per coding guidelines: "Use explicit type annotations for function parameters and return types in TypeScript".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/monograph/createMonograph.ts` around lines
26 - 29, The exported handler createMonograph currently relies on inferred
return types; add an explicit return type to the function signature (e.g.,
Promise<YourResponseType> or the specific handler result type used across
handlers) and ensure the async callback passed to handleError is also explicitly
typed if required. Update the signature for createMonograph(opts: RouterOptions,
req: CreateMonographRequest, ctx: HandlerContext): <ExplicitReturnType> and, if
needed, annotate the inner async () => { ... } callback with the same or
compatible return type so TypeScript no longer infers the handler result from
handleError usage.

controlplane/src/core/bufservices/monograph/publishMonograph.ts (1)

18-21: Please keep the exported handler’s return type explicit.

Line 18 and Line 21 currently depend on inference. This conflicts with the repository TS rule for explicit function return types.

Proposed patch

-export function publishMonograph(opts: RouterOptions, req: PublishMonographRequest, ctx: HandlerContext) {
+export function publishMonograph(
+  opts: RouterOptions,
+  req: PublishMonographRequest,
+  ctx: HandlerContext,
+): Promise<PublishMonographResponse> {
   let logger = getLogger(ctx, opts.logger);

-  return handleError(ctx, logger, async () => {
+  return handleError(ctx, logger, async (): Promise<PublishMonographResponse> => {

As per coding guidelines: "Use explicit type annotations for function parameters and return types in TypeScript".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/monograph/publishMonograph.ts` around lines
18 - 21, Add an explicit return type to the exported handler publishMonograph:
update the signature export function publishMonograph(opts: RouterOptions, req:
PublishMonographRequest, ctx: HandlerContext): Promise<PublishMonographResponse>
(or the concrete promise type that handleError returns) and import that response
type if needed; ensure the annotated return type matches the value returned by
handleError/getLogger so the function no longer relies on inference.

controlplane/src/core/repositories/analytics/AnalyticsDashboardViewRepository.ts (1)

316-336: Avoid using any type; define a proper interface for the metrics shape.

The use of any[] and any for metrics and metric variables weakens type safety. Since the object shape is well-defined with subgraphID, requestRate, errorRate, and latency, consider using a typed interface or directly using SubgraphMetrics type.

♻️ Proposed refactor to restore type safety

   private async getSubgraphMetricsView(
     federatedGraphId: string,
     organizationId: string,
     dateRange: DateRange<number>,
     subgraphs: SubgraphDTO[],
     rangeInHours: number,
-  ) {
-    const metrics: any[] = [];
+  ): Promise<{ subgraphID: string; requestRate: number; errorRate: number; latency: number }[]> {
+    const metrics: { subgraphID: string; requestRate: number; errorRate: number; latency: number }[] = [];

     if (subgraphs.length === 0) {
       return metrics;
     }

     const [requestRates, latency] = await Promise.all([
       this.getSubgraphRates(federatedGraphId, organizationId, dateRange, subgraphs, rangeInHours),
       this.getSubgraphLatency(federatedGraphId, organizationId, dateRange, subgraphs),
     ]);

     for (const subgraph of subgraphs) {
       const rate = requestRates.find((r) => r.subgraphID === subgraph.id);
       const lat = latency.find((l) => l.subgraphID === subgraph.id);
-      const metric: any = {
+      const metric = {
         subgraphID: subgraph.id,
         requestRate: 0,
         errorRate: 0,
         latency: 0,
       };

As per coding guidelines: "Avoid any type in TypeScript; use specific types or generics".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@controlplane/src/core/repositories/analytics/AnalyticsDashboardViewRepository.ts`
around lines 316 - 336, Replace the use of any for the metrics collection with a
proper typed interface (e.g., SubgraphMetrics) and update the local variables in
AnalyticsDashboardViewRepository to use it: define an interface with subgraphID:
string, requestRate: number, errorRate: number, latency: number (or reuse an
existing SubgraphMetrics type if present), change metrics: any[] to metrics:
SubgraphMetrics[] and metric: any to metric: SubgraphMetrics, and ensure
getSubgraphRates/getSubgraphLatency return compatible typed results or map their
outputs to SubgraphMetrics before pushing into the metrics array.

controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts (1)

56-56: Consider replacing any[] with a specific type.

Same as in getFederatedGraphById.ts, the requestSeries variable could benefit from explicit typing.

♻️ Proposed refactor

-    let requestSeries: any[] = [];
+    let requestSeries: { timestamp: string; totalRequests: number; erroredRequests: number }[] = [];

As per coding guidelines: "Avoid any type in TypeScript; use specific types or generics".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts`
at line 56, Replace the loose any[] declaration for requestSeries in
getFederatedGraphByName with the concrete type used in getFederatedGraphById;
locate the type used there (e.g., RequestSeriesItem or RequestSeries) and
annotate requestSeries as that array type (e.g., RequestSeriesItem[]), or define
a matching interface if none exists; update the declaration of requestSeries in
the getFederatedGraphByName function to use that explicit type and adjust any
push/usage sites to satisfy the typed shape.

controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts (1)

53-53: Consider replacing any[] with a specific type.

The requestSeries variable could use a more descriptive type matching the shape returned by getWeeklyRequestSeries.

♻️ Proposed refactor

-    let requestSeries: any[] = [];
+    let requestSeries: { timestamp: string; totalRequests: number; erroredRequests: number }[] = [];

As per coding guidelines: "Avoid any type in TypeScript; use specific types or generics".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts`
at line 53, Replace the loose any[] on requestSeries with a proper type that
matches the shape returned by getWeeklyRequestSeries: locate requestSeries in
getFederatedGraphById and change its declaration to use either a named interface
(e.g., WeeklyRequestPoint[] or WeeklyRequestSeries[]) that you create to mirror
the return shape, or use TypeScript's utility type like ReturnType<typeof
getWeeklyRequestSeries> (e.g., let requestSeries: ReturnType<typeof
getWeeklyRequestSeries> = [];). Ensure the chosen type matches the fields
returned by getWeeklyRequestSeries and import or declare it near
getFederatedGraphById.

controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts (1)

51-51: Consider using a more specific type instead of any[].

The requestSeriesList is typed as Record<string, any[]>, which loses compile-time type checking. Since this holds request series items with known properties (timestamp, totalRequests, erroredRequests), consider defining an interface or using the RequestSeriesItem import (already present).

♻️ Proposed refactor

-    const requestSeriesList: Record<string, any[]> = {};
+    const requestSeriesList: Record<string, { timestamp: string; totalRequests: number; erroredRequests: number }[]> = {};

As per coding guidelines: "Avoid any type in TypeScript; use specific types or generics".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts` at
line 51, The requestSeriesList variable is currently typed as Record<string,
any[]> which loses type safety; change its type to use the existing
RequestSeriesItem type (or define an interface with timestamp, totalRequests,
erroredRequests) so it becomes Record<string, RequestSeriesItem[]>; update the
declaration of requestSeriesList and any places that push into or read from it
(e.g., where items are created or iterated) to ensure they conform to
RequestSeriesItem properties and remove usages of any.

controlplane/test/graph-pruning.test.ts (1)

260-264: Split response variables to avoid as any casting.

Lines 260-264 and 421-425 reuse the resp variable for different RPC response types and cast with as any. Separate these into distinct variables—e.g., createSubgraphResp and publishInitialResp—to preserve type safety as per TypeScript guidelines.

Suggested refactor

-    let resp = await client.createFederatedSubgraph({
+    const createSubgraphResp = await client.createFederatedSubgraph({
       name: subgraphName,
       namespace: 'default',
       labels: [label],
       routingUrl: 'http://localhost:8080',
     });

-    expect(resp.response?.code).toBe(EnumStatusCode.OK);
+    expect(createSubgraphResp.response?.code).toBe(EnumStatusCode.OK);

-    resp = (await client.publishFederatedSubgraph({
+    const publishInitialResp = await client.publishFederatedSubgraph({
       name: subgraphName,
       namespace: 'default',
       schema: initSchema,
-    })) as any;
+    });

-    expect(resp.response?.code).toBe(EnumStatusCode.OK);
+    expect(publishInitialResp.response?.code).toBe(EnumStatusCode.OK);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/test/graph-pruning.test.ts` around lines 260 - 264, The test
reuses a single variable resp and casts to any when handling different RPC
responses from client.publishFederatedSubgraph (and the later call around lines
421-425), losing TypeScript type safety; split into distinct, correctly typed
variables (e.g., createSubgraphResp, publishInitialResp) for each RPC result,
remove the as any casts, and update subsequent references to use the new
variable names so each response retains its proper RPC return type.

controlplane/src/core/bufservices/contract/updateContract.ts (1)

22-25: Add an explicit return type back on updateContract.

The handler signature lost explicit return typing; please keep an explicit return contract for this function (and, if needed, a typed handleError path) to preserve type clarity at the boundary.

As per coding guidelines, "Use explicit type annotations for function parameters and return types in TypeScript".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/contract/updateContract.ts` around lines 22
- 25, The updateContract function lost its explicit return type; add a concrete
return annotation on updateContract (e.g., export function updateContract(opts:
RouterOptions, req: UpdateContractRequest, ctx: HandlerContext):
Promise<UpdateContractResponse>) so the handler boundary is typed, and if
handleError's signature doesn't already match, add/adjust an overload or generic
for handleError to return the same Promise<UpdateContractResponse> type; update
the function signature for updateContract and adjust handleError's typing (or
its call site generic) accordingly.

controlplane/src/core/bufservices/proposal/createProposal.ts (1)

29-32: Keep the handler return type explicit.

Removing the annotation here makes this exported RPC boundary depend on inference across a lot of early-return branches. Please keep an explicit v2 response type on createProposal instead of leaving the return shape implicit.

Suggested adjustment

-export function createProposal(opts: RouterOptions, req: CreateProposalRequest, ctx: HandlerContext) {
+export function createProposal(
+  opts: RouterOptions,
+  req: CreateProposalRequest,
+  ctx: HandlerContext,
+): Promise<CreateProposalResponse> {

As per coding guidelines, "Use explicit type annotations for function parameters and return types in TypeScript".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/proposal/createProposal.ts` around lines 29
- 32, The createProposal RPC handler currently omits an explicit return type;
add an explicit v2 response annotation to the function signature (e.g., export
function createProposal(opts: RouterOptions, req: CreateProposalRequest, ctx:
HandlerContext): Promise<CreateProposalResponseV2> ) so the exported RPC
boundary does not rely on inference across early returns; update or import the
correct v2 response type name (CreateProposalResponseV2 or equivalent) and
ensure the return value of the async handleError block matches that declared
type.

controlplane/src/core/repositories/CacheWarmerRepository.ts (1)

201-235: Extract the Operation builder before these branches drift.

The same nested request/client assembly now lives in multiple branches with slightly different default handling. A small helper for constructing OperationSchema payloads would make future field additions much harder to miss in one path.

Also applies to: 268-336

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/repositories/CacheWarmerRepository.ts` around lines 201
- 235, The duplicated logic building an OperationSchema (using create with
OperationRequestSchema and optional ClientInfoSchema) appears in multiple
branches (e.g., where persistedOperation.contents + persistedQuery vs
operation.operationContent are used); extract a small helper (e.g.,
buildOperation or buildOperationPayload) that accepts the request query and the
original operation metadata and returns the fully assembled
create(OperationSchema, { ... }) object so both branches call that helper with
either persistedOperation.contents or operation.operationContent; ensure the
helper also encapsulates the optional client creation (using ClientInfoSchema,
operation.clientName and operation.clientVersion) and sets operationName
consistently (operation.operationName || undefined) to avoid drift across the
branches.

studio/src/components/create-graph.tsx (1)

115-117: Drop the explicit cardinality: undefined.

This is already a method-scoped partial key, so the extra cardinality field does not narrow the refetch any further. Omitting it makes the intent clearer and keeps the call aligned with the partial-key usage Connect Query documents. (github.com)

♻️ Proposed cleanup

           await queryClient.refetchQueries({
-            queryKey: createConnectQueryKey({ schema: getWorkspace, cardinality: undefined }),
+            queryKey: createConnectQueryKey({ schema: getWorkspace }),
           });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@studio/src/components/create-graph.tsx` around lines 115 - 117, Remove the
unnecessary explicit cardinality: undefined from the refetch call — update the
queryClient.refetchQueries invocation that uses createConnectQueryKey({ schema:
getWorkspace, cardinality: undefined }) to call createConnectQueryKey with only
the method-scoped partial key (e.g., createConnectQueryKey({ schema:
getWorkspace })), so the partial-key semantics are preserved and the call aligns
with Connect Query documents; modify the code around queryClient.refetchQueries
and createConnectQueryKey accordingly.

studio/src/pages/[organizationSlug]/members.tsx (1)

458-468: Invalidate pending-member queries by method instead of the current filter tuple.

This file has more than one getPendingOrganizationMembers query, and they do not all derive search from the same source. Tying the invalidation to the current { pagination, search } object makes the refresh brittle; a method-level partial key is safer and still matches the active pending-members queries after invite success. (tanstack.com)

♻️ Proposed cleanup

-                const pendingKey = createConnectQueryKey({
-                  schema: getPendingOrganizationMembers,
-                  input: {
-                    pagination: {
-                      limit: pageSize,
-                      offset,
-                    },
-                    search,
-                  },
-                  cardinality: 'finite',
-                });
+                const pendingKey = createConnectQueryKey({
+                  schema: getPendingOrganizationMembers,
+                  cardinality: 'finite',
+                });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@studio/src/pages/`[organizationSlug]/members.tsx around lines 458 - 468, The
current invalidation builds pendingKey with the full { pagination, search }
input which is brittle; instead construct the key at the method/schema level so
all pending-members queries are matched. Replace the pendingKey expression that
uses createConnectQueryKey({... input: { pagination, search } ...}) with a
schema-level partial key using createConnectQueryKey({ schema:
getPendingOrganizationMembers }) (or same call with an empty/undefined input)
and use that for invalidateQueries so all variants of
getPendingOrganizationMembers are refreshed after invite success.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@controlplane/src/core/bufservices/analytics/getOperations.ts`:
- Around line 28-31: The getOperations function is missing an explicit return
type; update the function signature for getOperations(opts: RouterOptions, req:
GetOperationsRequest, ctx: HandlerContext) to include the correct explicit
return type that matches the asynchronous handler result (for example
Promise<GetOperationsResponse> or the actual handler result type used by
handleError). Ensure the return type you add exactly matches what
handleError(...) resolves to so the handler contract is explicit and typesafe.

In `@controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts`:
- Around line 108-110: Replace the three untyped arrays with explicit protobuf
types to restore type safety: change compositionErrors: any[] to
compositionErrors: CompositionError[], deploymentErrors: any[] to
deploymentErrors: DeploymentError[], and compositionWarnings: any[] to
compositionWarnings: CompositionWarning[] (they can remain initialized as []);
the required types CompositionError, DeploymentError, and CompositionWarning are
already imported—update the variable declarations accordingly.

In `@controlplane/src/core/bufservices/federated-graph/checkFederatedGraph.ts`:
- Around line 28-31: Add an explicit return type to the checkFederatedGraph
function (e.g., Promise<CheckFederatedGraphResponse>) and replace the two uses
of any[] with the correct imported types: use CompositionWarning[] where
composition warnings are returned and CompositionError[] where composition
errors are returned (replace the arrays at the sites currently using any[]).
Ensure the file imports CompositionWarning and CompositionError if not already
imported and update the variable/return type annotations inside
checkFederatedGraph (and any intermediate vars) to use these concrete array
types so the function signature and internal types are fully and explicitly
typed.
- Line 140: Replace the loose any[] types with the concrete protobuf types:
change the declarations of compositionWarnings and compositionErrors to use
CompositionWarning[] and CompositionError[] respectively so the arrays carry the
proper shape and compiler checks; locate the declarations for
compositionWarnings (currently "const compositionWarnings: any[] = [];") and
compositionErrors (currently "const compositionErrors: any[] = [];") and update
their types to CompositionWarning[] and CompositionError[] (import or reference
the exported protobuf types if not already imported) so assignments to those
arrays match the four fields (message, federatedGraphName, namespace,
featureFlag).

In `@controlplane/src/core/bufservices/federated-graph/createFederatedGraph.ts`:
- Around line 214-216: Replace the three any[] declarations with their proper
protobuf types to restore type safety: change compositionErrors: any[] to
compositionErrors: CompositionError[], deploymentErrors: any[] to
deploymentErrors: DeploymentError[], and compositionWarnings: any[] to
compositionWarnings: CompositionWarning[] (these types are already imported and
used when pushing into the arrays, so just update the variable type annotations
for compositionErrors, deploymentErrors, and compositionWarnings).
- Around line 23-26: The exported handler createFederatedGraph currently relies
on inference; update its signature to include an explicit return type (e.g.
export function createFederatedGraph(opts: RouterOptions, req:
CreateFederatedGraphRequest, ctx: HandlerContext): Promise<ReturnType<typeof
handleError>> { ... }) so the exported boundary has a clear contract; adjust the
concrete Promise/return type if your project has a specific HandlerResult type
and ensure the annotation is added where createFederatedGraph is declared
(references: createFederatedGraph, RouterOptions, CreateFederatedGraphRequest,
HandlerContext, handleError).

In
`@controlplane/src/core/bufservices/federated-graph/getClientsFromAnalytics.ts`:
- Around line 13-16: Add an explicit return type to the exported function
getClientsFromAnalytics: change its signature to declare it returns
Promise<GetClientsFromAnalyticsResponse>. Ensure imports/types used
(RouterOptions, GetClientsFromAnalyticsRequest, HandlerContext) remain the same
and that the function body which calls handleError(ctx, logger, async () => {
... }) matches the declared Promise<GetClientsFromAnalyticsResponse> return
type.

In `@controlplane/src/core/bufservices/federated-graph/getRouters.ts`:
- Around line 13-16: The handler getRouters currently omits an explicit return
type and lets handleError infer the response type, and uses any[] for the router
array; add an explicit return type (e.g., Promise<GetRoutersResponse>) to
getRouters, call handleError with the generic type
handleError<GetRoutersResponse>(...), and replace the any[] router array with
the concrete router type from the schema (e.g., Router[] or the exact type used
in the service model) so types are enforced and schema drift is caught early;
update references to GetRoutersResponse and the concrete Router type in the
function body accordingly.
- Line 50: Replace the untyped array declaration to use the concrete Router
type: change the declaration of routers (currently "const routers: any[] = [];")
to use Router[] so the array is strongly typed; ensure the Router import is used
and that any pushes into routers (in getRouters or related helper functions)
conform to the Router shape, updating any construction sites to satisfy the
Router type if necessary.

In `@controlplane/src/core/bufservices/graph/recomposeGraph.ts`:
- Around line 16-19: The exported handler function recomposeGraph currently
omits an explicit return type; update its signature to include the correct
TypeScript return annotation (e.g., the handler response Promise/HandlerResult
type used across other handlers) so the function declaration export function
recomposeGraph(opts: RouterOptions, req: RecomposeGraphRequest, ctx:
HandlerContext): <ReturnType> { ... } explicitly types the return value; ensure
the type aligns with what handleError/getLogger expect and matches other
handlers' signatures to restore the handler contract.

In `@controlplane/src/core/bufservices/linting/getNamespaceLintConfig.ts`:
- Around line 15-18: The handler getNamespaceLintConfig currently omits an
explicit return type; update its signature to include the correct return type
(e.g., the Promise-wrapped response type expected from this handler) so it no
longer relies on inference. Modify the declaration of
getNamespaceLintConfig(opts: RouterOptions, req: GetNamespaceLintConfigRequest,
ctx: HandlerContext): <ExplicitReturnType> and ensure the return type matches
what handleError(...) returns for this handler; keep RouterOptions,
GetNamespaceLintConfigRequest, HandlerContext and handleError references intact
when choosing the precise type.

In `@controlplane/src/core/bufservices/organization/deleteOrganizationGroup.ts`:
- Line 17: Add an explicit return type to the deleteOrganizationGroup function
signature (export function deleteOrganizationGroup(opts: RouterOptions, req:
DeleteOrganizationGroupRequest, ctx: HandlerContext):
Promise<DeleteOrganizationGroupResponse> { ... }) matching the type inferred
from handleError; if that exact type differs in your codebase use the precise
inferred Promise/response type, and import/declare
DeleteOrganizationGroupResponse (or the correct response type) so the function
signature is fully annotated.

---

Outside diff comments:
In `@controlplane/src/core/repositories/CacheWarmerRepository.ts`:
- Around line 514-524: The serialization call
Buffer.from(toJsonString(CacheWarmerOperationsSchema, cacheWarmerOperations),
'utf8') is outside the try/catch so any serialization error bypasses the
upload-failure handling; move the toJsonString + Buffer.from steps inside the
existing try block that surrounds blobStorage.putObject so both serialization
and upload errors are caught and logged together (update references to
cacheWarmerOperationsBytes, CacheWarmerOperationsSchema, toJsonString, path and
blobStorage.putObject accordingly).

In `@controlplane/src/core/repositories/OrganizationRepository.ts`:
- Around line 747-765: getWebhookMeta builds an untyped any[] (meta) and then
casts to EventMeta[], which hides type mismatches; fix by producing
properly-typed protobuf messages or adjusting the signature: either construct
EventMeta instances (or PlainMessage<EventMeta> objects) using the generated
protobuf constructors/types instead of pushing plain any objects into meta in
getWebhookMeta, or change the method return type to
Promise<PlainMessage<EventMeta>[]> (and propagate that change) so the code uses
the correct intermediate type; update references in the function to create
values matching EventMeta (or PlainMessage<EventMeta>) rather than using any.
- Around line 1168-1176: Replace the loose "const config: any" with the
generated IntegrationConfig type and construct the object to match the oneof
structure exactly (e.g., for Slack use IntegrationType.SLACK, case:
'slackIntegrationConfig', value: { endpoint: slackIntegrationConfig.endpoint })
so the compiler checks the case/value pairing; do the same for the other branch
(lines 1224-1232) so both integration config objects are typed as
IntegrationConfig from the generated schema and assigned to integrationConfig
without using any.
- Around line 1560-1568: The getWebhookHistory method currently returns
deliveries: any[] which disables type-checking for the transformed payload;
define a specific DTO type (e.g., WebhookDeliveryHistoryItem) describing the
transformed shape (id, organizationId, type, endpoint, eventName, payload,
createdAt as ISO string, createdBy?, isRedelivery, requestHeaders as JSON
string, responseHeaders?, responseStatusCode?, responseErrorCode?,
responseBody?, errorMessage?, etc.) and update the method signature to Promise<{
deliveries: WebhookDeliveryHistoryItem[]; totalCount: number }>, then ensure the
mapping inside getWebhookHistory constructs objects that conform to
WebhookDeliveryHistoryItem so TS will validate the transformation.

---

Duplicate comments:
In `@controlplane/src/core/bufservices/contract/updateContract.ts`:
- Around line 155-157: The three accumulators compositionErrors,
deploymentErrors, and compositionWarnings are typed as any[]; replace them with
concrete types (e.g., CompositionError[], DeploymentError[],
CompositionWarning[] or appropriate existing interfaces) by importing or
declaring the correct interfaces and updating all usages and the surrounding
return/response types in updateContract to match; ensure you update any function
signatures or result objects that include these arrays so the compiler enforces
the correct shape and remove any remaining casts to any.

In `@controlplane/src/core/bufservices/namespace/deleteNamespace.ts`:
- Around line 16-19: The function deleteNamespace currently relies on an
inferred return type; update its signature to explicitly declare the return type
Promise<DeleteNamespaceResponse> (e.g., export function deleteNamespace(opts:
RouterOptions, req: DeleteNamespaceRequest, ctx: HandlerContext):
Promise<DeleteNamespaceResponse>) so callers and the handler contract are
clear—adjust any related overloads or imports if necessary and ensure the
implementation (including the call to handleError) still returns a
Promise<DeleteNamespaceResponse>.

---

Nitpick comments:
In `@controlplane/src/core/bufservices/check/getCheckSummary.ts`:
- Around line 25-28: Add an explicit return type annotation to the
getCheckSummary function signature (which currently takes RouterOptions,
GetCheckSummaryRequest, HandlerContext) to match the inferred return type from
the async handler (for example, Promise<GetCheckSummaryResponse> or the actual
inferred type in your codebase); update the function declaration for
getCheckSummary to include that explicit return type to follow the project's
TypeScript style guidelines.

In `@controlplane/src/core/bufservices/contract/updateContract.ts`:
- Around line 22-25: The updateContract function lost its explicit return type;
add a concrete return annotation on updateContract (e.g., export function
updateContract(opts: RouterOptions, req: UpdateContractRequest, ctx:
HandlerContext): Promise<UpdateContractResponse>) so the handler boundary is
typed, and if handleError's signature doesn't already match, add/adjust an
overload or generic for handleError to return the same
Promise<UpdateContractResponse> type; update the function signature for
updateContract and adjust handleError's typing (or its call site generic)
accordingly.

In `@controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts`:
- Around line 22-25: Add an explicit return type to the deleteFeatureFlag
function signature (e.g. Promise<DeleteFeatureFlagResponse> or the appropriate
PlainMessage-wrapped variant your handler returns) so the function reads like:
export function deleteFeatureFlag(...): Promise<DeleteFeatureFlagResponse> { ...
}; ensure the type you choose matches the value returned inside the handleError
callback and import the DeleteFeatureFlagResponse type if not already imported.

In `@controlplane/src/core/bufservices/federated-graph/getCompositionDetails.ts`:
- Around line 14-17: getCompositionDetails currently relies on an inferred
return type after removing the PlainMessage wrapper; add an explicit return type
annotation for the function (e.g., the appropriate Promise<...> type or a
specific response type) to comply with the project's TypeScript guidelines and
improve documentation. Locate the function declaration for getCompositionDetails
and annotate its signature with the correct return type that matches the value
returned by the async handleError callback (using the types used in this file
such as RouterOptions, GetCompositionDetailsRequest, HandlerContext and the
actual response type produced by the handler).

In `@controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts`:
- Line 53: Replace the loose any[] on requestSeries with a proper type that
matches the shape returned by getWeeklyRequestSeries: locate requestSeries in
getFederatedGraphById and change its declaration to use either a named interface
(e.g., WeeklyRequestPoint[] or WeeklyRequestSeries[]) that you create to mirror
the return shape, or use TypeScript's utility type like ReturnType<typeof
getWeeklyRequestSeries> (e.g., let requestSeries: ReturnType<typeof
getWeeklyRequestSeries> = [];). Ensure the chosen type matches the fields
returned by getWeeklyRequestSeries and import or declare it near
getFederatedGraphById.

In
`@controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts`:
- Line 56: Replace the loose any[] declaration for requestSeries in
getFederatedGraphByName with the concrete type used in getFederatedGraphById;
locate the type used there (e.g., RequestSeriesItem or RequestSeries) and
annotate requestSeries as that array type (e.g., RequestSeriesItem[]), or define
a matching interface if none exists; update the declaration of requestSeries in
the getFederatedGraphByName function to use that explicit type and adjust any
push/usage sites to satisfy the typed shape.

In `@controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts`:
- Line 51: The requestSeriesList variable is currently typed as Record<string,
any[]> which loses type safety; change its type to use the existing
RequestSeriesItem type (or define an interface with timestamp, totalRequests,
erroredRequests) so it becomes Record<string, RequestSeriesItem[]>; update the
declaration of requestSeriesList and any places that push into or read from it
(e.g., where items are created or iterated) to ensure they conform to
RequestSeriesItem properties and remove usages of any.

In `@controlplane/src/core/bufservices/monograph/createMonograph.ts`:
- Around line 26-29: The exported handler createMonograph currently relies on
inferred return types; add an explicit return type to the function signature
(e.g., Promise<YourResponseType> or the specific handler result type used across
handlers) and ensure the async callback passed to handleError is also explicitly
typed if required. Update the signature for createMonograph(opts: RouterOptions,
req: CreateMonographRequest, ctx: HandlerContext): <ExplicitReturnType> and, if
needed, annotate the inner async () => { ... } callback with the same or
compatible return type so TypeScript no longer infers the handler result from
handleError usage.

In `@controlplane/src/core/bufservices/monograph/publishMonograph.ts`:
- Around line 18-21: Add an explicit return type to the exported handler
publishMonograph: update the signature export function publishMonograph(opts:
RouterOptions, req: PublishMonographRequest, ctx: HandlerContext):
Promise<PublishMonographResponse> (or the concrete promise type that handleError
returns) and import that response type if needed; ensure the annotated return
type matches the value returned by handleError/getLogger so the function no
longer relies on inference.

In `@controlplane/src/core/bufservices/proposal/createProposal.ts`:
- Around line 29-32: The createProposal RPC handler currently omits an explicit
return type; add an explicit v2 response annotation to the function signature
(e.g., export function createProposal(opts: RouterOptions, req:
CreateProposalRequest, ctx: HandlerContext): Promise<CreateProposalResponseV2> )
so the exported RPC boundary does not rely on inference across early returns;
update or import the correct v2 response type name (CreateProposalResponseV2 or
equivalent) and ensure the return value of the async handleError block matches
that declared type.

In `@controlplane/src/core/bufservices/subgraph/checkSubgraphSchema.ts`:
- Around line 32-35: Add an explicit return type to the checkSubgraphSchema
function declaration (which currently takes RouterOptions,
CheckSubgraphSchemaRequest and HandlerContext) instead of relying on inference;
determine the exact return type by inspecting the handleError<T>() utility used
in the body (or the concrete response wrapper used elsewhere in the Connect v2
migration) and annotate the function with that type so all ~10 return paths are
checked by the compiler and shape mismatches are caught at compile time.

In
`@controlplane/src/core/repositories/analytics/AnalyticsDashboardViewRepository.ts`:
- Around line 316-336: Replace the use of any for the metrics collection with a
proper typed interface (e.g., SubgraphMetrics) and update the local variables in
AnalyticsDashboardViewRepository to use it: define an interface with subgraphID:
string, requestRate: number, errorRate: number, latency: number (or reuse an
existing SubgraphMetrics type if present), change metrics: any[] to metrics:
SubgraphMetrics[] and metric: any to metric: SubgraphMetrics, and ensure
getSubgraphRates/getSubgraphLatency return compatible typed results or map their
outputs to SubgraphMetrics before pushing into the metrics array.

In `@controlplane/src/core/repositories/CacheWarmerRepository.ts`:
- Around line 201-235: The duplicated logic building an OperationSchema (using
create with OperationRequestSchema and optional ClientInfoSchema) appears in
multiple branches (e.g., where persistedOperation.contents + persistedQuery vs
operation.operationContent are used); extract a small helper (e.g.,
buildOperation or buildOperationPayload) that accepts the request query and the
original operation metadata and returns the fully assembled
create(OperationSchema, { ... }) object so both branches call that helper with
either persistedOperation.contents or operation.operationContent; ensure the
helper also encapsulates the optional client creation (using ClientInfoSchema,
operation.clientName and operation.clientVersion) and sets operationName
consistently (operation.operationName || undefined) to avoid drift across the
branches.

In `@controlplane/test/graph-pruning.test.ts`:
- Around line 260-264: The test reuses a single variable resp and casts to any
when handling different RPC responses from client.publishFederatedSubgraph (and
the later call around lines 421-425), losing TypeScript type safety; split into
distinct, correctly typed variables (e.g., createSubgraphResp,
publishInitialResp) for each RPC result, remove the as any casts, and update
subsequent references to use the new variable names so each response retains its
proper RPC return type.

In `@studio/src/components/create-graph.tsx`:
- Around line 115-117: Remove the unnecessary explicit cardinality: undefined
from the refetch call — update the queryClient.refetchQueries invocation that
uses createConnectQueryKey({ schema: getWorkspace, cardinality: undefined }) to
call createConnectQueryKey with only the method-scoped partial key (e.g.,
createConnectQueryKey({ schema: getWorkspace })), so the partial-key semantics
are preserved and the call aligns with Connect Query documents; modify the code
around queryClient.refetchQueries and createConnectQueryKey accordingly.

In `@studio/src/pages/`[organizationSlug]/members.tsx:
- Around line 458-468: The current invalidation builds pendingKey with the full
{ pagination, search } input which is brittle; instead construct the key at the
method/schema level so all pending-members queries are matched. Replace the
pendingKey expression that uses createConnectQueryKey({... input: { pagination,
search } ...}) with a schema-level partial key using createConnectQueryKey({
schema: getPendingOrganizationMembers }) (or same call with an empty/undefined
input) and use that for invalidateQueries so all variants of
getPendingOrganizationMembers are refreshed after invite success.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@composition-go/shim/src/polyfill.js`:
- Around line 19-31: The current polyfill TextDecoder.decode implementation can
throw URIError on malformed UTF-8 because it uses
decodeURIComponent(escape(str)); update the TextDecoder class (the decode
method) to defensively handle invalid byte sequences: wrap the
decodeURIComponent(escape(str)) call in a try-catch and on error return a
replacement-string where invalid sequences are replaced with U+FFFD (the Unicode
replacement character) or otherwise fall back to iterating bytes and emitting
U+FFFD for invalid UTF-8 sequences; ensure the method still returns an empty
string for falsy input and preserves existing behavior for valid UTF-8.

In `@connect/src/wg/cosmo/notifications/events_pb.ts`:
- Around line 18-23: The three protobuf message symbols GraphSchemaUpdatedMeta,
ProposalStateUpdatedMeta, and EventMeta are only used as types and must be
imported with "import type" instead of value imports; update the import
statements that currently pull these symbols alongside OrganizationEventName and
any *Schema runtime objects by splitting into two imports: one "import type {
GraphSchemaUpdatedMeta, ProposalStateUpdatedMeta, EventMeta } from '...';" for
the type-only symbols and a separate normal import for OrganizationEventName and
the *Schema runtime objects so the enum and runtime schemas remain value imports
while the message types are type-only.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 5325b0d3-a3f6-4436-8d10-558e9f897349

📥 Commits

Reviewing files that changed from the base of the PR and between 232cd9b and de02fae.

📒 Files selected for processing (9)

• buf.ts.gen.yaml
• composition-go/index.global.js
• composition-go/shim/src/polyfill.js
• connect/src/wg/cosmo/common/common_pb.ts
• connect/src/wg/cosmo/node/v1/node-NodeService_connectquery.ts
• connect/src/wg/cosmo/node/v1/node_pb.ts
• connect/src/wg/cosmo/notifications/events_pb.ts
• connect/src/wg/cosmo/platform/v1/platform-PlatformService_connectquery.ts
• connect/src/wg/cosmo/platform/v1/platform_pb.ts

🚧 Files skipped from review as they are similar to previous changes (3)

• buf.ts.gen.yaml
• connect/src/wg/cosmo/node/v1/node-NodeService_connectquery.ts
• connect/src/wg/cosmo/common/common_pb.ts

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Expectation:
# 1) No non-`import type` imports remain for EventMeta / GraphSchemaUpdatedMeta / ProposalStateUpdatedMeta.
# 2) No runtime-style protobuf usage remains for those symbols.
# 3) If any tsconfig enables verbatimModuleSyntax/preserveValueImports, check (1) must be clean.

echo "== Non-type imports of type-only protobuf messages =="
rg -nPU --type=ts --type=tsx \
  '(?s)^\s*import(?!\s+type)\s*\{[^}]*\b(EventMeta|GraphSchemaUpdatedMeta|ProposalStateUpdatedMeta)\b[^}]*\}\s*from\s*["'\''][^"'\'']*notifications/events_pb(?:\.js)?["'\'']' .

echo
echo "== Runtime-style usage that no longer works with type-only message exports =="
rg -nP --type=ts --type=tsx \
  '\b(new\s+(EventMeta|GraphSchemaUpdatedMeta|ProposalStateUpdatedMeta)\b|(EventMeta|GraphSchemaUpdatedMeta|ProposalStateUpdatedMeta)\.(fromBinary|fromJson|fromJsonString|equals)\b|instanceof\s+(EventMeta|GraphSchemaUpdatedMeta|ProposalStateUpdatedMeta)\b)' .

echo
echo "== TS compiler flags that make value-importing type-only exports fail =="
python - <<'PY'
import json
from pathlib import Path

for path in Path('.').rglob('tsconfig*.json'):
    if any(part in {'node_modules', 'dist'} for part in path.parts):
        continue
    try:
        data = json.loads(path.read_text())
    except Exception:
        continue
    opts = data.get('compilerOptions', {})
    flags = {
        'verbatimModuleSyntax': opts.get('verbatimModuleSyntax'),
        'preserveValueImports': opts.get('preserveValueImports'),
        'importsNotUsedAsValues': opts.get('importsNotUsedAsValues'),
    }
    if any(value is not None for value in flags.values()):
        print(f"{path}: {flags}")
PY

Repository: wundergraph/cosmo

Length of output: 159

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== Non-type imports of type-only protobuf messages =="
# Use -t ts (ripgrep recognizes ts and tsx automatically when using -t ts)
rg -nP --type ts \
  'import\s*\{[^}]*\b(EventMeta|GraphSchemaUpdatedMeta|ProposalStateUpdatedMeta)\b[^}]*\}\s*from\s*["'"'"'][^"'"'"']*notifications/events_pb' . || echo "No matches found"

echo
echo "== Checking specific files mentioned in the review =="
echo "File: studio/src/components/notifications/components.tsx"
if [ -f "studio/src/components/notifications/components.tsx" ]; then
  head -30 "studio/src/components/notifications/components.tsx" | cat -n
else
  echo "File not found"
fi

echo
echo "File: controlplane/src/core/webhooks/OrganizationWebhookService.ts"
if [ -f "controlplane/src/core/webhooks/OrganizationWebhookService.ts" ]; then
  head -30 "controlplane/src/core/webhooks/OrganizationWebhookService.ts" | cat -n
else
  echo "File not found"
fi

echo
echo "== Runtime-style usage (new/fromBinary/instanceof) =="
rg -nP --type ts \
  '\b(new\s+(EventMeta|GraphSchemaUpdatedMeta|ProposalStateUpdatedMeta)|EventMeta\.fromBinary|GraphSchemaUpdatedMeta\.fromBinary|ProposalStateUpdatedMeta\.fromBinary|instanceof\s+(EventMeta|GraphSchemaUpdatedMeta|ProposalStateUpdatedMeta))\b' . || echo "No runtime usage found"

echo
echo "== TypeScript compiler strict flags =="
python3 - <<'PY'
import json
from pathlib import Path

found_any = False
for path in sorted(Path('.').rglob('tsconfig*.json')):
    if any(part in {'node_modules', 'dist', '.next'} for part in path.parts):
        continue
    try:
        data = json.loads(path.read_text())
    except Exception:
        continue
    opts = data.get('compilerOptions', {})
    # Check for strict flags that would cause issues with value-importing type-only exports
    if (opts.get('verbatimModuleSyntax') or 
        opts.get('preserveValueImports') or 
        opts.get('importsNotUsedAsValues')):
        found_any = True
        print(f"{path}:")
        for flag in ['verbatimModuleSyntax', 'preserveValueImports', 'importsNotUsedAsValues']:
            val = opts.get(flag)
            if val is not None:
                print(f"  {flag}: {val}")

if not found_any:
    print("No strict TypeScript import flags found in tsconfig files")
PY

Repository: wundergraph/cosmo

Length of output: 4378

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== Check exports of events_pb.ts for OrganizationEventName =="
grep -n "OrganizationEventName" "connect/src/wg/cosmo/notifications/events_pb.ts" | head -20

echo
echo "== Verify EventMeta usage in OrganizationWebhookService.ts =="
rg -A 20 "EventMeta" "controlplane/src/core/webhooks/OrganizationWebhookService.ts" | head -40

echo
echo "== Verify EventMeta usage in OrganizationRepository.ts =="
rg -A 10 "EventMeta" "controlplane/src/core/repositories/OrganizationRepository.ts" | head -30

echo
echo "== Check what EventMetaSchema and similar are =="
grep -n "export.*EventMetaSchema\|export.*GraphSchemaUpdatedMetaSchema\|export.*ProposalStateUpdatedMetaSchema" "connect/src/wg/cosmo/notifications/events_pb.ts"

echo
echo "== Full context of export lines 18-80 =="
sed -n '18,80p' "connect/src/wg/cosmo/notifications/events_pb.ts"

Repository: wundergraph/cosmo

Length of output: 5710

---

Use import type for type-only message symbols to follow TypeScript best practices.

GraphSchemaUpdatedMeta, ProposalStateUpdatedMeta, and EventMeta are now type-only exports. Four files currently use value-style imports for these symbols but only reference them in type positions:

• controlplane/src/core/webhooks/OrganizationWebhookService.ts:1
• controlplane/src/core/repositories/OrganizationRepository.ts:1
• controlplane/test/proposal/proposal-webhooks.test.ts:2
• controlplane/test/integrations.test.ts:2

Split these imports to use import type for the message symbols while keeping value imports for OrganizationEventName (enum) and the *Schema runtime objects. This ensures compatibility if verbatimModuleSyntax or strict import rules are later enabled in TypeScript config.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@connect/src/wg/cosmo/notifications/events_pb.ts` around lines 18 - 23, The
three protobuf message symbols GraphSchemaUpdatedMeta, ProposalStateUpdatedMeta,
and EventMeta are only used as types and must be imported with "import type"
instead of value imports; update the import statements that currently pull these
symbols alongside OrganizationEventName and any *Schema runtime objects by
splitting into two imports: one "import type { GraphSchemaUpdatedMeta,
ProposalStateUpdatedMeta, EventMeta } from '...';" for the type-only symbols and
a separate normal import for OrganizationEventName and the *Schema runtime
objects so the enum and runtime schemas remain value imports while the message
types are type-only.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts`:
- Around line 17-20: The function getFederatedGraphs is missing an explicit
return type which causes TypeScript to infer handleError's generics; update the
function signature to include the explicit RPC return type (for example
Promise<GetFederatedGraphsResponse> or the exact RPC response type used in this
service) alongside the existing parameters (RouterOptions,
GetFederatedGraphsRequest, HandlerContext) so the compiler no longer infers the
generic from handleError and the RPC contract stays type-safe; ensure
imports/types used in the annotation match the project's RPC response type
names.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 5aa961d2-5dbb-4b23-80c2-5e10f97b8758

📥 Commits

Reviewing files that changed from the base of the PR and between de02fae and 81b41ee.

⛔ Files ignored due to path filters (1)

• demo/pkg/subgraphs/courses/bun.lock is excluded by !**/*.lock

📒 Files selected for processing (16)

• controlplane/package.json
• controlplane/src/core/bufservices/contract/createContract.ts
• controlplane/src/core/bufservices/contract/updateContract.ts
• controlplane/src/core/bufservices/feature-flag/createFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/enableFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/updateFeatureFlag.ts
• controlplane/src/core/bufservices/federated-graph/checkFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts
• controlplane/src/core/bufservices/federated-graph/getRouters.ts
• controlplane/src/core/bufservices/federated-graph/moveFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/updateFederatedGraph.ts
• controlplane/src/core/bufservices/subgraph/fixSubgraphSchema.ts

🚧 Files skipped from review as they are similar to previous changes (11)

• controlplane/package.json
• controlplane/src/core/bufservices/feature-flag/enableFeatureFlag.ts
• controlplane/src/core/bufservices/contract/updateContract.ts
• controlplane/src/core/bufservices/federated-graph/getRouters.ts
• controlplane/src/core/bufservices/subgraph/fixSubgraphSchema.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts
• controlplane/src/core/bufservices/federated-graph/moveFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/updateFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts
• controlplane/src/core/bufservices/federated-graph/checkFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraph.ts

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (6)

controlplane/src/core/bufservices/api-key/getAPIKeys.ts (1)

7-7: Use a type-only import for PlainMessage.

PlainMessage is a type-only export and used only in type positions (return type and generic). Using import type is the idiomatic TypeScript approach.

♻️ Suggested change

-import { PlainMessage } from '../../../types/index.js';
+import type { PlainMessage } from '../../../types/index.js';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/api-key/getAPIKeys.ts` at line 7, The
import of PlainMessage in getAPIKeys.ts is a type-only usage; change the import
to a type-only import by replacing the current named import with an import type
for PlainMessage (update the import statement that references PlainMessage from
'../../../types/index.js'), ensuring all usages (return type and generic in
getAPIKeys) remain unchanged and no runtime import is introduced.

controlplane/src/core/bufservices/billing/createCheckoutSession.ts (1)

12-12: Use a type-only import for PlainMessage.

PlainMessage is used only as a type in the return type and generic parameter, so this should be import type to follow the project's TypeScript conventions.

♻️ Proposed fix

-import { PlainMessage } from '../../../types/index.js';
+import type { PlainMessage } from '../../../types/index.js';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/billing/createCheckoutSession.ts` at line
12, The import of PlainMessage in createCheckoutSession.ts is used only as a
type; change the import to a type-only import by replacing the current import of
PlainMessage with an "import type" form so PlainMessage is treated as a
compile-time-only type (affecting usages in the return type and generic
parameter in createCheckoutSession).

controlplane/src/core/bufservices/federated-graph/getFederatedGraphSDLByName.ts (1)

13-13: Use a type-only import for PlainMessage.

At Line 13, PlainMessage is used only as a type (at Lines 19 and 21). Importing it as a value is inconsistent with TypeScript best practices and the type-only export in controlplane/src/types/index.ts.

Proposed change

-import { PlainMessage } from '../../../types/index.js';
+import type { PlainMessage } from '../../../types/index.js';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@controlplane/src/core/bufservices/federated-graph/getFederatedGraphSDLByName.ts`
at line 13, The import of PlainMessage should be type-only: update the import
statement that currently imports PlainMessage as a value to a type-only import
(e.g., use "import type { PlainMessage } from '...';") in the module that
defines getFederatedGraphSDLByName so the PlainMessage symbol is only imported
as a TypeScript type (used in the function signature and variable annotations at
the call sites within getFederatedGraphSDLByName).

controlplane/src/core/bufservices/organization/isMemberLimitReached.ts (1)

10-10: Use a type-only import for PlainMessage on line 10.

PlainMessage is a type-only export used exclusively in type positions (return type and generic argument). Add the type keyword to make the intent explicit and follow TypeScript best practices.

Suggested change

-import { PlainMessage } from '../../../types/index.js';
+import type { PlainMessage } from '../../../types/index.js';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/organization/isMemberLimitReached.ts` at
line 10, Change the import of PlainMessage to a type-only import: update the
import statement that currently reads "import { PlainMessage } from '...';" to
"import type { PlainMessage } from '...';" so PlainMessage is explicitly treated
as a type (used in the isMemberLimitReached return type and generic arguments).

controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphs.ts (1)

11-11: Use a type-only import for PlainMessage.

At line 11, PlainMessage is only used in type positions (lines 13 and 16). Switching to import type makes this explicit and aligns with idiomatic TypeScript.

Suggested change

-import { PlainMessage } from '../../../types/index.js';
+import type { PlainMessage } from '../../../types/index.js';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphs.ts` at
line 11, Change the value import of PlainMessage to a type-only import since
it’s only used in type positions (e.g., in the getFeatureSubgraphs-related types
at lines where PlainMessage appears). Replace the current import statement for
PlainMessage with an import type { PlainMessage } ... so TypeScript treats it as
a type-only import, eliminating unnecessary runtime import emission and aligning
with idiomatic usage.

controlplane/src/core/bufservices/analytics/getOperations.ts (1)

208-217: Avoid using any type for operationData.

The operationData variable is typed as any, which bypasses TypeScript's type checking and violates coding guidelines. Consider using a more specific type or the partial message type that create() expects.

♻️ Suggested improvement

Since you're passing this to create(GetOperationsResponse_OperationSchema, operationData), you could type it as a partial of the expected input:

-      const operationData: any = {
+      const operationData: Parameters<typeof create<typeof GetOperationsResponse_OperationSchema>>[1] = {
         name: operation.operationName,
         hash: operation.operationHash,
         type:

Alternatively, build the object inline within the create() call or define an interface that matches the expected shape.

As per coding guidelines: **/*.{ts,tsx}: Avoid any type in TypeScript; use specific types or generics.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@controlplane/src/core/bufservices/analytics/getOperations.ts` around lines
208 - 217, operationData is typed as any; replace it with a specific type that
matches the payload expected by create(GetOperationsResponse_OperationSchema,
...). Define a proper type (or use a Partial of the schema's input type) that
includes name: string, hash: string, and type:
GetOperationsResponse_OperationType, then declare operationData with that type
instead of any and pass it into create(); this ensures operationData (the object
built for the create() call) is type-checked against
GetOperationsResponse_OperationSchema/GetOperationsResponse_OperationType.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@controlplane/src/core/bufservices/api-key/deleteAPIKey.ts`:
- Line 11: The import for PlainMessage is a type-only usage and should be
changed to a type-only import to avoid emitting a runtime import; replace the
current import statement that references PlainMessage with an import type
declaration (e.g. use "import type { PlainMessage } from
'../../../types/index.js'") so TypeScript treats PlainMessage as a
compile-time-only type.

In `@controlplane/src/core/bufservices/check/getCheckSummary.ts`:
- Line 24: The import for PlainMessage is a type-only export but is currently
imported as a value; change the import statement to a type-only import (use
"import type { PlainMessage } from '...';") in getCheckSummary.ts so
PlainMessage is only emitted for types; keep the same module path
('../../../types/index.js') but use import type to avoid runtime import emission
and ensure any function/type annotations that reference PlainMessage (e.g., the
getCheckSummary signatures/variables on Line 26 and Line 29) continue to
compile.

In `@controlplane/src/core/bufservices/organization/updateOrganizationDetails.ts`:
- Line 13: The import of PlainMessage should be a type-only import because
PlainMessage is only used in type positions (e.g., in the
updateOrganizationDetails function/type annotations); replace the existing
import statement "import { PlainMessage }" with a type import "import type {
PlainMessage }" so the compiler treats it as a type-only import and avoids
emitting runtime imports.

---

Nitpick comments:
In `@controlplane/src/core/bufservices/analytics/getOperations.ts`:
- Around line 208-217: operationData is typed as any; replace it with a specific
type that matches the payload expected by
create(GetOperationsResponse_OperationSchema, ...). Define a proper type (or use
a Partial of the schema's input type) that includes name: string, hash: string,
and type: GetOperationsResponse_OperationType, then declare operationData with
that type instead of any and pass it into create(); this ensures operationData
(the object built for the create() call) is type-checked against
GetOperationsResponse_OperationSchema/GetOperationsResponse_OperationType.

In `@controlplane/src/core/bufservices/api-key/getAPIKeys.ts`:
- Line 7: The import of PlainMessage in getAPIKeys.ts is a type-only usage;
change the import to a type-only import by replacing the current named import
with an import type for PlainMessage (update the import statement that
references PlainMessage from '../../../types/index.js'), ensuring all usages
(return type and generic in getAPIKeys) remain unchanged and no runtime import
is introduced.

In `@controlplane/src/core/bufservices/billing/createCheckoutSession.ts`:
- Line 12: The import of PlainMessage in createCheckoutSession.ts is used only
as a type; change the import to a type-only import by replacing the current
import of PlainMessage with an "import type" form so PlainMessage is treated as
a compile-time-only type (affecting usages in the return type and generic
parameter in createCheckoutSession).

In `@controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphs.ts`:
- Line 11: Change the value import of PlainMessage to a type-only import since
it’s only used in type positions (e.g., in the getFeatureSubgraphs-related types
at lines where PlainMessage appears). Replace the current import statement for
PlainMessage with an import type { PlainMessage } ... so TypeScript treats it as
a type-only import, eliminating unnecessary runtime import emission and aligning
with idiomatic usage.

In
`@controlplane/src/core/bufservices/federated-graph/getFederatedGraphSDLByName.ts`:
- Line 13: The import of PlainMessage should be type-only: update the import
statement that currently imports PlainMessage as a value to a type-only import
(e.g., use "import type { PlainMessage } from '...';") in the module that
defines getFederatedGraphSDLByName so the PlainMessage symbol is only imported
as a TypeScript type (used in the function signature and variable annotations at
the call sites within getFederatedGraphSDLByName).

In `@controlplane/src/core/bufservices/organization/isMemberLimitReached.ts`:
- Line 10: Change the import of PlainMessage to a type-only import: update the
import statement that currently reads "import { PlainMessage } from '...';" to
"import type { PlainMessage } from '...';" so PlainMessage is explicitly treated
as a type (used in the isMemberLimitReached return type and generic arguments).

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d961b2dd-422d-4a8d-94e4-f082133ff922

📥 Commits

Reviewing files that changed from the base of the PR and between 81b41ee and db3fd4d.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (178)

• controlplane/src/core/bufservices/analytics/getAnalyticsView.ts
• controlplane/src/core/bufservices/analytics/getDashboardAnalyticsView.ts
• controlplane/src/core/bufservices/analytics/getFieldUsage.ts
• controlplane/src/core/bufservices/analytics/getGraphMetrics.ts
• controlplane/src/core/bufservices/analytics/getMetricsErrorRate.ts
• controlplane/src/core/bufservices/analytics/getOperationClients.ts
• controlplane/src/core/bufservices/analytics/getOperationContent.ts
• controlplane/src/core/bufservices/analytics/getOperationDeprecatedFields.ts
• controlplane/src/core/bufservices/analytics/getOperations.ts
• controlplane/src/core/bufservices/analytics/getOrganizationRequestsCount.ts
• controlplane/src/core/bufservices/analytics/getSubgraphMetrics.ts
• controlplane/src/core/bufservices/analytics/getSubgraphMetricsErrorRate.ts
• controlplane/src/core/bufservices/analytics/getTrace.ts
• controlplane/src/core/bufservices/api-key/createAPIKey.ts
• controlplane/src/core/bufservices/api-key/deleteAPIKey.ts
• controlplane/src/core/bufservices/api-key/getAPIKeys.ts
• controlplane/src/core/bufservices/api-key/updateAPIKey.ts
• controlplane/src/core/bufservices/api-key/verifyAPIKeyGraphAccess.ts
• controlplane/src/core/bufservices/billing/createBillingPortalSession.ts
• controlplane/src/core/bufservices/billing/createCheckoutSession.ts
• controlplane/src/core/bufservices/billing/getBillingPlans.ts
• controlplane/src/core/bufservices/billing/upgradePlan.ts
• controlplane/src/core/bufservices/cache-warmer/computeCacheWarmerOperations.ts
• controlplane/src/core/bufservices/cache-warmer/configureCacheWarmer.ts
• controlplane/src/core/bufservices/cache-warmer/deleteCacheWarmerOperation.ts
• controlplane/src/core/bufservices/cache-warmer/getCacheWarmerConfig.ts
• controlplane/src/core/bufservices/cache-warmer/getCacheWarmerOperations.ts
• controlplane/src/core/bufservices/cache-warmer/pushCacheWarmerOperation.ts
• controlplane/src/core/bufservices/check-extensions/configureSubgraphCheckExtensions.ts
• controlplane/src/core/bufservices/check-extensions/getSubgraphCheckExtensionsConfig.ts
• controlplane/src/core/bufservices/check/createIgnoreOverridesForAllOperations.ts
• controlplane/src/core/bufservices/check/createOperationIgnoreAllOverride.ts
• controlplane/src/core/bufservices/check/createOperationOverrides.ts
• controlplane/src/core/bufservices/check/forceCheckSuccess.ts
• controlplane/src/core/bufservices/check/getAllOverrides.ts
• controlplane/src/core/bufservices/check/getCheckOperations.ts
• controlplane/src/core/bufservices/check/getCheckSummary.ts
• controlplane/src/core/bufservices/check/getChecksByFederatedGraphName.ts
• controlplane/src/core/bufservices/check/getNamespaceChecksConfig.ts
• controlplane/src/core/bufservices/check/getOperationOverrides.ts
• controlplane/src/core/bufservices/check/getProposedSchemaOfCheckedSubgraph.ts
• controlplane/src/core/bufservices/check/isGitHubAppInstalled.ts
• controlplane/src/core/bufservices/check/removeOperationIgnoreAllOverride.ts
• controlplane/src/core/bufservices/check/removeOperationOverrides.ts
• controlplane/src/core/bufservices/check/toggleChangeOverridesForAllOperations.ts
• controlplane/src/core/bufservices/check/updateNamespaceChecksConfig.ts
• controlplane/src/core/bufservices/contract/createContract.ts
• controlplane/src/core/bufservices/contract/updateContract.ts
• controlplane/src/core/bufservices/feature-flag/createFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/enableFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlagByName.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlags.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlagsByFederatedGraph.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphs.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphsByFeatureFlag.ts
• controlplane/src/core/bufservices/feature-flag/updateFeatureFlag.ts
• controlplane/src/core/bufservices/federated-graph/checkFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraphToken.ts
• controlplane/src/core/bufservices/federated-graph/deleteFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/deleteRouterToken.ts
• controlplane/src/core/bufservices/federated-graph/generateRouterToken.ts
• controlplane/src/core/bufservices/federated-graph/getClientsFromAnalytics.ts
• controlplane/src/core/bufservices/federated-graph/getCompositionDetails.ts
• controlplane/src/core/bufservices/federated-graph/getCompositions.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphChangelog.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphSDLByName.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphsBySubgraphLabels.ts
• controlplane/src/core/bufservices/federated-graph/getRouterTokens.ts
• controlplane/src/core/bufservices/federated-graph/getRouters.ts
• controlplane/src/core/bufservices/federated-graph/migrateFromApollo.ts
• controlplane/src/core/bufservices/federated-graph/moveFederatedGraph.ts
• controlplane/src/core/bufservices/federated-graph/updateFederatedGraph.ts
• controlplane/src/core/bufservices/graph/recomposeGraph.ts
• controlplane/src/core/bufservices/graph/setGraphRouterCompatibilityVersion.ts
• controlplane/src/core/bufservices/linting/configureNamespaceGraphPruningConfig.ts
• controlplane/src/core/bufservices/linting/configureNamespaceLintConfig.ts
• controlplane/src/core/bufservices/linting/enableGraphPruning.ts
• controlplane/src/core/bufservices/linting/enableLintingForTheNamespace.ts
• controlplane/src/core/bufservices/linting/getNamespaceGraphPruningConfig.ts
• controlplane/src/core/bufservices/linting/getNamespaceLintConfig.ts
• controlplane/src/core/bufservices/monograph/createMonograph.ts
• controlplane/src/core/bufservices/monograph/deleteMonograph.ts
• controlplane/src/core/bufservices/monograph/migrateMonograph.ts
• controlplane/src/core/bufservices/monograph/moveMonograph.ts
• controlplane/src/core/bufservices/monograph/publishMonograph.ts
• controlplane/src/core/bufservices/monograph/updateMonograph.ts
• controlplane/src/core/bufservices/namespace/createNamespace.ts
• controlplane/src/core/bufservices/namespace/deleteNamespace.ts
• controlplane/src/core/bufservices/namespace/getNamespace.ts
• controlplane/src/core/bufservices/namespace/getNamespaces.ts
• controlplane/src/core/bufservices/namespace/renameNamespace.ts
• controlplane/src/core/bufservices/notification/createIntegration.ts
• controlplane/src/core/bufservices/notification/createOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/notification/deleteIntegration.ts
• controlplane/src/core/bufservices/notification/deleteOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/notification/getOrganizationIntegrations.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookConfigs.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookHistory.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookMeta.ts
• controlplane/src/core/bufservices/notification/getWebhookDeliveryDetails.ts
• controlplane/src/core/bufservices/notification/redeliverWebhook.ts
• controlplane/src/core/bufservices/notification/updateIntegrationConfig.ts
• controlplane/src/core/bufservices/notification/updateOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/organization/createOrganization.ts
• controlplane/src/core/bufservices/organization/createOrganizationGroup.ts
• controlplane/src/core/bufservices/organization/deleteOrganization.ts
• controlplane/src/core/bufservices/organization/deleteOrganizationGroup.ts
• controlplane/src/core/bufservices/organization/getAuditLogs.ts
• controlplane/src/core/bufservices/organization/getOrganizationBySlug.ts
• controlplane/src/core/bufservices/organization/getOrganizationGroupMembers.ts
• controlplane/src/core/bufservices/organization/getOrganizationGroups.ts
• controlplane/src/core/bufservices/organization/getOrganizationMembers.ts
• controlplane/src/core/bufservices/organization/getPendingOrganizationMembers.ts
• controlplane/src/core/bufservices/organization/isMemberLimitReached.ts
• controlplane/src/core/bufservices/organization/leaveOrganization.ts
• controlplane/src/core/bufservices/organization/listOrganizations.ts
• controlplane/src/core/bufservices/organization/restoreOrganization.ts
• controlplane/src/core/bufservices/organization/updateFeatureSettings.ts
• controlplane/src/core/bufservices/organization/updateOrganizationDetails.ts
• controlplane/src/core/bufservices/organization/updateOrganizationGroup.ts
• controlplane/src/core/bufservices/organization/whoAmI.ts
• controlplane/src/core/bufservices/persisted-operation/check-persisted-operation-traffic.ts
• controlplane/src/core/bufservices/persisted-operation/deletePersistedOperation.ts
• controlplane/src/core/bufservices/persisted-operation/getClients.ts
• controlplane/src/core/bufservices/persisted-operation/getPersistedOperations.ts
• controlplane/src/core/bufservices/persisted-operation/publishPersistedOperations.ts
• controlplane/src/core/bufservices/playground/createPlaygroundScript.ts
• controlplane/src/core/bufservices/playground/deletePlaygroundScript.ts
• controlplane/src/core/bufservices/playground/getPlaygroundScripts.ts
• controlplane/src/core/bufservices/playground/updatePlaygroundScript.ts
• controlplane/src/core/bufservices/plugin/validateAndFetchPluginData.ts
• controlplane/src/core/bufservices/proposal/configureNamespaceProposalConfig.ts
• controlplane/src/core/bufservices/proposal/createProposal.ts
• controlplane/src/core/bufservices/proposal/enableProposalsForNamespace.ts
• controlplane/src/core/bufservices/proposal/getNamespaceProposalConfig.ts
• controlplane/src/core/bufservices/proposal/getProposal.ts
• controlplane/src/core/bufservices/proposal/getProposalChecks.ts
• controlplane/src/core/bufservices/proposal/getProposalsByFederatedGraph.ts
• controlplane/src/core/bufservices/proposal/updateProposal.ts
• controlplane/src/core/bufservices/router/listRouterCompatibilityVersions.ts
• controlplane/src/core/bufservices/schema-version/getChangelogBySchemaVersion.ts
• controlplane/src/core/bufservices/schema-version/getSdlBySchemaVersion.ts
• controlplane/src/core/bufservices/sso/createOIDCProvider.ts
• controlplane/src/core/bufservices/sso/deleteOIDCProvider.ts
• controlplane/src/core/bufservices/sso/getOIDCProvider.ts
• controlplane/src/core/bufservices/sso/updateIDPMappers.ts
• controlplane/src/core/bufservices/subgraph/addReadme.ts
• controlplane/src/core/bufservices/subgraph/checkSubgraphSchema.ts
• controlplane/src/core/bufservices/subgraph/createFederatedSubgraph.ts
• controlplane/src/core/bufservices/subgraph/deleteFederatedSubgraph.ts
• controlplane/src/core/bufservices/subgraph/fixSubgraphSchema.ts
• controlplane/src/core/bufservices/subgraph/getLatestSubgraphSDL.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphById.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphByName.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphMembers.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphSDLFromLatestComposition.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphs.ts
• controlplane/src/core/bufservices/subgraph/linkSubgraph.ts
• controlplane/src/core/bufservices/subgraph/moveSubgraph.ts
• controlplane/src/core/bufservices/subgraph/publishFederatedSubgraph.ts
• controlplane/src/core/bufservices/subgraph/unlinkSubgraph.ts
• controlplane/src/core/bufservices/subgraph/updateSubgraph.ts
• controlplane/src/core/bufservices/user/acceptOrDeclineInvitation.ts
• controlplane/src/core/bufservices/user/deleteUser.ts
• controlplane/src/core/bufservices/user/getInvitations.ts
• controlplane/src/core/bufservices/user/getUserAccessiblePermissions.ts
• controlplane/src/core/bufservices/user/getUserAccessibleResources.ts
• controlplane/src/core/bufservices/user/initializeCosmoUser.ts
• controlplane/src/core/bufservices/user/inviteUser.ts
• controlplane/src/core/bufservices/user/removeInvitation.ts
• controlplane/src/core/bufservices/user/removeOrganizationMember.ts
• controlplane/src/core/bufservices/user/updateOrgMemberGroup.ts
• controlplane/src/core/bufservices/workspace/getWorkspace.ts

✅ Files skipped from review due to trivial changes (38)

• controlplane/src/core/bufservices/subgraph/getSubgraphSDLFromLatestComposition.ts
• controlplane/src/core/bufservices/subgraph/publishFederatedSubgraph.ts
• controlplane/src/core/bufservices/check-extensions/getSubgraphCheckExtensionsConfig.ts
• controlplane/src/core/bufservices/notification/deleteOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureSubgraphsByFeatureFlag.ts
• controlplane/src/core/bufservices/proposal/configureNamespaceProposalConfig.ts
• controlplane/src/core/bufservices/federated-graph/getClientsFromAnalytics.ts
• controlplane/src/core/bufservices/check/createIgnoreOverridesForAllOperations.ts
• controlplane/src/core/bufservices/graph/setGraphRouterCompatibilityVersion.ts
• controlplane/src/core/bufservices/analytics/getSubgraphMetrics.ts
• controlplane/src/core/bufservices/monograph/deleteMonograph.ts
• controlplane/src/core/bufservices/organization/getOrganizationBySlug.ts
• controlplane/src/core/bufservices/user/initializeCosmoUser.ts
• controlplane/src/core/bufservices/federated-graph/getRouterTokens.ts
• controlplane/src/core/bufservices/namespace/renameNamespace.ts
• controlplane/src/core/bufservices/organization/leaveOrganization.ts
• controlplane/src/core/bufservices/cache-warmer/deleteCacheWarmerOperation.ts
• controlplane/src/core/bufservices/check/getAllOverrides.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphByName.ts
• controlplane/src/core/bufservices/billing/upgradePlan.ts
• controlplane/src/core/bufservices/subgraph/addReadme.ts
• controlplane/src/core/bufservices/subgraph/deleteFederatedSubgraph.ts
• controlplane/src/core/bufservices/check/createOperationOverrides.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookConfigs.ts
• controlplane/src/core/bufservices/playground/updatePlaygroundScript.ts
• controlplane/src/core/bufservices/subgraph/checkSubgraphSchema.ts
• controlplane/src/core/bufservices/federated-graph/generateRouterToken.ts
• controlplane/src/core/bufservices/organization/deleteOrganizationGroup.ts
• controlplane/src/core/bufservices/federated-graph/getRouters.ts
• controlplane/src/core/bufservices/linting/configureNamespaceLintConfig.ts
• controlplane/src/core/bufservices/proposal/getNamespaceProposalConfig.ts
• controlplane/src/core/bufservices/subgraph/fixSubgraphSchema.ts
• controlplane/src/core/bufservices/check/getChecksByFederatedGraphName.ts
• controlplane/src/core/bufservices/federated-graph/migrateFromApollo.ts
• controlplane/src/core/bufservices/analytics/getOperationDeprecatedFields.ts
• controlplane/src/core/bufservices/persisted-operation/deletePersistedOperation.ts
• controlplane/src/core/bufservices/cache-warmer/pushCacheWarmerOperation.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlags.ts

🚧 Files skipped from review as they are similar to previous changes (112)

• controlplane/src/core/bufservices/analytics/getSubgraphMetricsErrorRate.ts
• controlplane/src/core/bufservices/check/getProposedSchemaOfCheckedSubgraph.ts
• controlplane/src/core/bufservices/billing/createBillingPortalSession.ts
• controlplane/src/core/bufservices/analytics/getGraphMetrics.ts
• controlplane/src/core/bufservices/notification/getWebhookDeliveryDetails.ts
• controlplane/src/core/bufservices/notification/getOrganizationIntegrations.ts
• controlplane/src/core/bufservices/check/removeOperationOverrides.ts
• controlplane/src/core/bufservices/user/getUserAccessibleResources.ts
• controlplane/src/core/bufservices/schema-version/getSdlBySchemaVersion.ts
• controlplane/src/core/bufservices/persisted-operation/getClients.ts
• controlplane/src/core/bufservices/feature-flag/deleteFeatureFlag.ts
• controlplane/src/core/bufservices/organization/getOrganizationMembers.ts
• controlplane/src/core/bufservices/playground/getPlaygroundScripts.ts
• controlplane/src/core/bufservices/check/toggleChangeOverridesForAllOperations.ts
• controlplane/src/core/bufservices/check-extensions/configureSubgraphCheckExtensions.ts
• controlplane/src/core/bufservices/user/acceptOrDeclineInvitation.ts
• controlplane/src/core/bufservices/notification/updateIntegrationConfig.ts
• controlplane/src/core/bufservices/analytics/getOrganizationRequestsCount.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookMeta.ts
• controlplane/src/core/bufservices/linting/getNamespaceLintConfig.ts
• controlplane/src/core/bufservices/analytics/getOperationContent.ts
• controlplane/src/core/bufservices/proposal/enableProposalsForNamespace.ts
• controlplane/src/core/bufservices/billing/getBillingPlans.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphByName.ts
• controlplane/src/core/bufservices/user/removeOrganizationMember.ts
• controlplane/src/core/bufservices/check/getNamespaceChecksConfig.ts
• controlplane/src/core/bufservices/check/isGitHubAppInstalled.ts
• controlplane/src/core/bufservices/notification/createOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphsBySubgraphLabels.ts
• controlplane/src/core/bufservices/linting/enableLintingForTheNamespace.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphChangelog.ts
• controlplane/src/core/bufservices/organization/createOrganizationGroup.ts
• controlplane/src/core/bufservices/api-key/updateAPIKey.ts
• controlplane/src/core/bufservices/cache-warmer/getCacheWarmerOperations.ts
• controlplane/src/core/bufservices/federated-graph/updateFederatedGraph.ts
• controlplane/src/core/bufservices/check/forceCheckSuccess.ts
• controlplane/src/core/bufservices/user/inviteUser.ts
• controlplane/src/core/bufservices/subgraph/unlinkSubgraph.ts
• controlplane/src/core/bufservices/organization/getPendingOrganizationMembers.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraphToken.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphMembers.ts
• controlplane/src/core/bufservices/analytics/getFieldUsage.ts
• controlplane/src/core/bufservices/contract/createContract.ts
• controlplane/src/core/bufservices/notification/updateOrganizationWebhookConfig.ts
• controlplane/src/core/bufservices/playground/deletePlaygroundScript.ts
• controlplane/src/core/bufservices/notification/deleteIntegration.ts
• controlplane/src/core/bufservices/linting/configureNamespaceGraphPruningConfig.ts
• controlplane/src/core/bufservices/sso/updateIDPMappers.ts
• controlplane/src/core/bufservices/linting/getNamespaceGraphPruningConfig.ts
• controlplane/src/core/bufservices/namespace/createNamespace.ts
• controlplane/src/core/bufservices/api-key/createAPIKey.ts
• controlplane/src/core/bufservices/monograph/migrateMonograph.ts
• controlplane/src/core/bufservices/organization/createOrganization.ts
• controlplane/src/core/bufservices/notification/createIntegration.ts
• controlplane/src/core/bufservices/organization/getAuditLogs.ts
• controlplane/src/core/bufservices/plugin/validateAndFetchPluginData.ts
• controlplane/src/core/bufservices/analytics/getMetricsErrorRate.ts
• controlplane/src/core/bufservices/sso/getOIDCProvider.ts
• controlplane/src/core/bufservices/check/getCheckOperations.ts
• controlplane/src/core/bufservices/user/getInvitations.ts
• controlplane/src/core/bufservices/cache-warmer/configureCacheWarmer.ts
• controlplane/src/core/bufservices/monograph/updateMonograph.ts
• controlplane/src/core/bufservices/proposal/updateProposal.ts
• controlplane/src/core/bufservices/federated-graph/createFederatedGraph.ts
• controlplane/src/core/bufservices/organization/listOrganizations.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphById.ts
• controlplane/src/core/bufservices/organization/getOrganizationGroups.ts
• controlplane/src/core/bufservices/subgraph/moveSubgraph.ts
• controlplane/src/core/bufservices/sso/createOIDCProvider.ts
• controlplane/src/core/bufservices/analytics/getOperationClients.ts
• controlplane/src/core/bufservices/feature-flag/enableFeatureFlag.ts
• controlplane/src/core/bufservices/schema-version/getChangelogBySchemaVersion.ts
• controlplane/src/core/bufservices/feature-flag/updateFeatureFlag.ts
• controlplane/src/core/bufservices/organization/restoreOrganization.ts
• controlplane/src/core/bufservices/sso/deleteOIDCProvider.ts
• controlplane/src/core/bufservices/feature-flag/getFeatureFlagsByFederatedGraph.ts
• controlplane/src/core/bufservices/user/updateOrgMemberGroup.ts
• controlplane/src/core/bufservices/organization/whoAmI.ts
• controlplane/src/core/bufservices/cache-warmer/getCacheWarmerConfig.ts
• controlplane/src/core/bufservices/federated-graph/moveFederatedGraph.ts
• controlplane/src/core/bufservices/namespace/getNamespaces.ts
• controlplane/src/core/bufservices/notification/redeliverWebhook.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphById.ts
• controlplane/src/core/bufservices/federated-graph/deleteRouterToken.ts
• controlplane/src/core/bufservices/subgraph/linkSubgraph.ts
• controlplane/src/core/bufservices/organization/updateOrganizationGroup.ts
• controlplane/src/core/bufservices/monograph/publishMonograph.ts
• controlplane/src/core/bufservices/federated-graph/getCompositionDetails.ts
• controlplane/src/core/bufservices/monograph/moveMonograph.ts
• controlplane/src/core/bufservices/user/removeInvitation.ts
• controlplane/src/core/bufservices/persisted-operation/publishPersistedOperations.ts
• controlplane/src/core/bufservices/persisted-operation/getPersistedOperations.ts
• controlplane/src/core/bufservices/federated-graph/getCompositions.ts
• controlplane/src/core/bufservices/user/deleteUser.ts
• controlplane/src/core/bufservices/contract/updateContract.ts
• controlplane/src/core/bufservices/check/removeOperationIgnoreAllOverride.ts
• controlplane/src/core/bufservices/organization/getOrganizationGroupMembers.ts
• controlplane/src/core/bufservices/notification/getOrganizationWebhookHistory.ts
• controlplane/src/core/bufservices/namespace/deleteNamespace.ts
• controlplane/src/core/bufservices/subgraph/getLatestSubgraphSDL.ts
• controlplane/src/core/bufservices/workspace/getWorkspace.ts
• controlplane/src/core/bufservices/api-key/verifyAPIKeyGraphAccess.ts
• controlplane/src/core/bufservices/router/listRouterCompatibilityVersions.ts
• controlplane/src/core/bufservices/subgraph/createFederatedSubgraph.ts
• controlplane/src/core/bufservices/monograph/createMonograph.ts
• controlplane/src/core/bufservices/proposal/getProposal.ts
• controlplane/src/core/bufservices/linting/enableGraphPruning.ts
• controlplane/src/core/bufservices/federated-graph/deleteFederatedGraph.ts
• controlplane/src/core/bufservices/subgraph/getSubgraphs.ts
• controlplane/src/core/bufservices/user/getUserAccessiblePermissions.ts
• controlplane/src/core/bufservices/federated-graph/getFederatedGraphs.ts
• controlplane/src/core/bufservices/proposal/createProposal.ts

[comatory]

@JivusAyrus I pulled the branch down, ran into few problems which was caused by stale builds, so I had to run pnpm -r build to rebuild all the deps. I clicked through the studio app and did not notice anything out of ordinary.