fix(api): customerIdOrKey entitlement param type#3093
Conversation
📝 Walkthrough""" WalkthroughThis change updates the type of the Changes
Possibly related PRs
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Biome (1.9.4)api/client/javascript/src/zod/index.tsThe --json option is unstable/experimental and its output might change between patches/minor releases. ... [truncated 99999040 characters] ... eryParams = zod.object({\n channel: zod\n .array(\n zod.coerce\n .string()\n .regex(listNotificationEventsQueryChannelItemRegExp)\n .describe(\n 'ULID (Universally Unique Lexicographically Sortable Identifier).'\n )\n )\n .optional()\n .describe(\n 'Filtering by multiple channel ids.\n\nUsage: `?chanBiome encountered an unexpected error This is a bug in Biome, not an error in your code, and we would appreciate it if you could report it to https://github.com/biomejs/biome/issues/ along with the following information to help us fixing the issue: Source Location: crates/biome_console/src/lib.rs:149:14 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (6)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
api/openapi.cloud.yaml (1)
3535-3539: Same concern as above – reference must resolve.This hunk repeats the
$refchange; the comment from lines 3247-3251 applies here as well.
🧹 Nitpick comments (2)
api/openapi.yaml (2)
3246-3250: Add/restore a helpful parameter descriptionThe previous inline schema likely carried a short description (e.g., “Customer ULID or external key”). With the switch to a
$ref, thedescriptionfield disappeared, reducing Swagger-UI usability. Consider re-adding it:in: path required: true schema: $ref: '#/components/schemas/ULIDOrExternalKey' +description: Customer ULID (26-char Crockford base32) or external key (≤256 chars)
3536-3537: Mirror the same improvement for the second endpointSame remark as above: keep a
descriptionalongside the$reffor consistency and better API docs.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
api/api.gen.go(7 hunks)api/client/go/client.gen.go(13 hunks)api/client/javascript/src/client/schemas.ts(2 hunks)api/client/javascript/src/zod/index.ts(3 hunks)api/openapi.cloud.yaml(2 hunks)api/openapi.yaml(2 hunks)api/spec/src/entitlements/customer.tsp(2 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: chrisgacsal
PR: openmeterio/openmeter#2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
api/spec/src/entitlements/customer.tsp (1)
Learnt from: chrisgacsal
PR: openmeterio/openmeter#2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
api/client/javascript/src/client/schemas.ts (1)
undefined
<retrieved_learning>
Learnt from: chrisgacsal
PR: #2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
</retrieved_learning>
api/client/javascript/src/zod/index.ts (1)
undefined
<retrieved_learning>
Learnt from: chrisgacsal
PR: #2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
</retrieved_learning>
api/openapi.yaml (1)
undefined
<retrieved_learning>
Learnt from: chrisgacsal
PR: #2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
</retrieved_learning>
api/openapi.cloud.yaml (1)
undefined
<retrieved_learning>
Learnt from: chrisgacsal
PR: #2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
</retrieved_learning>
api/api.gen.go (1)
undefined
<retrieved_learning>
Learnt from: chrisgacsal
PR: #2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
</retrieved_learning>
api/client/go/client.gen.go (1)
undefined
<retrieved_learning>
Learnt from: chrisgacsal
PR: #2522
File: api/spec/src/productcatalog/routes.tsp:163-314
Timestamp: 2025-03-25T09:13:03.300Z
Learning: ULIDOrKey is defined in api/spec/src/types.tsp as a scalar type with a pattern that validates against both ULID and Key formats, not as a type alias like PlanIdOrKey.
</retrieved_learning>
🧬 Code Graph Analysis (1)
api/api.gen.go (2)
api/client/go/client.gen.go (2)
ULIDOrExternalKey(6216-6216)GetCustomerEntitlementValueParams(6952-6954)openmeter/customer/httpdriver/customer.go (1)
GetCustomerEntitlementValueParams(333-336)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
- GitHub Check: Quickstart
- GitHub Check: E2E
- GitHub Check: CI
- GitHub Check: Commit hooks
- GitHub Check: Developer environment
- GitHub Check: Lint
- GitHub Check: Build
- GitHub Check: Test
- GitHub Check: Migration Checks
- GitHub Check: Analyze (go)
🔇 Additional comments (27)
api/spec/src/entitlements/customer.tsp (2)
35-35: LGTM! Consistent type usage.The type change is consistent with the previous change on line 22, ensuring both API endpoints use the same type for customer identification.
22-22: ULIDOrExternalKey type validated
Theunion ULIDOrExternalKeyis correctly defined in api/spec/src/types.tsp and is referenced without import issues in api/spec/src/entitlements/customer.tsp. All OpenAPI schemas and generated clients consistently use this type.api/client/javascript/src/client/schemas.ts (2)
15570-15572: Mirror change for feature-scoped route—same verification applies.Same concerns as above: ensure regenerated types are consumed everywhere and versioning communicates the breaking change. Consider adding migration notes to the changelog.
15178-15180: No residualcustomerIdOrKey: stringusages inapiI ran a search across the
apidirectory and found no instances ofcustomerIdOrKey: stringRemaining next steps to fully validate this breaking change:
- Confirm all generated client code has been regenerated to use
ULIDOrExternalKey.- Audit any handwritten call-sites (outside the generated code) to ensure none still accept a plain string.
- Verify the SDK/API version in
package.json(or equivalent) has been bumped (semver) to reflect this breaking change.api/openapi.yaml (1)
3248-3249: ULIDOrExternalKey schema is present and declared once
The#/components/schemas/ULIDOrExternalKeyreference inapi/openapi.yamlis valid—it's defined at line 22482. No further action required.api/openapi.cloud.yaml (1)
3247-3251: ULIDOrExternalKey schema definition confirmed
- Definition found at api/openapi.cloud.yaml line 21556
- References at lines 3045, 3113, 3186, 3250, 3319, 3389, 3467, 3538, 3623
All
$ref: '#/components/schemas/ULIDOrExternalKey'entries correctly resolve.api/client/javascript/src/zod/index.ts (3)
6969-6987: LGTM! Improved type safety with proper ULID validation.The implementation correctly splits the validation into two distinct cases:
- Strict ULID pattern validation with proper Crockford's Base32 encoding
- Permissive external key validation (1-256 characters)
The union type approach using
.or()provides the flexibility to accept either format while maintaining type safety.
7425-7427: Consistent constant definitions for entitlement value parameters.The naming convention with "RegExpOne" and "MaxTwo" suffixes effectively distinguishes between the ULID regex pattern and external key maximum length constraints.
7437-7447: Consistent validation schema implementation.The validation logic matches the implementation in
getCustomerAccessParams, ensuring consistent behavior across all customer identifier parameters in the API.api/api.gen.go (7)
11551-11551: LGTM: Parameter type updated for better type safety.The change from
stringtoULIDOrExternalKeyfor thecustomerIdOrKeyparameter provides better type validation and aligns with the PR objective to standardize customer identifier types across the API.
11563-11563: LGTM: Consistent parameter type update.The parameter type change maintains consistency with the
GetCustomerAccessmethod and follows the same pattern for customer identifier validation.
12091-12091: LGTM: Unimplemented stub updated to match interface.The parameter type change in the unimplemented method correctly reflects the interface update, maintaining code consistency and ensuring compilation.
12115-12115: LGTM: Unimplemented stub updated consistently.The parameter type change maintains consistency with the interface definition and ensures the unimplemented method signature matches the updated interface.
14162-14162: LGTM: Variable type updated for parameter binding.The variable type change from
stringtoULIDOrExternalKeyis necessary to match the updated method signature and ensure proper parameter binding in the server wrapper.
14298-14298: LGTM: Consistent variable type update.The variable type change maintains consistency with the previous parameter binding update and ensures proper type handling for the
GetCustomerEntitlementValuemethod.
18839-19057: Generated swagger specification updated.The embedded swagger specification has been updated to reflect the parameter type changes. Since this appears to be generated/encoded content, detailed review is not feasible, but the update is necessary to maintain consistency between the API implementation and documentation.
api/client/go/client.gen.go (11)
10772-10772: LGTM: Interface method signature updated correctly.The
GetCustomerAccessmethod signature has been properly updated to useULIDOrExternalKeytype for thecustomerIdOrKeyparameter, which aligns with the PR objective to standardize this parameter type across the API.
10786-10786: LGTM: Interface method signature updated consistently.The
GetCustomerEntitlementValuemethod signature has been properly updated to useULIDOrExternalKeytype, maintaining consistency with other methods in the interface.
11846-11846: LGTM: Implementation signature matches interface.The
GetCustomerAccessimplementation has been properly updated to match the interface signature change, ensuring type consistency across the client implementation.
11906-11906: LGTM: Implementation signature matches interface.The
GetCustomerEntitlementValueimplementation has been properly updated to match the interface signature change, maintaining consistency across the client implementation.
16031-16031: LGTM: Request constructor signature updated correctly.The
NewGetCustomerAccessRequestfunction signature has been properly updated to acceptULIDOrExternalKeytype, ensuring consistency with the calling client methods.
16241-16241: LGTM: Request constructor signature updated consistently.The
NewGetCustomerEntitlementValueRequestfunction signature has been properly updated to acceptULIDOrExternalKeytype, maintaining consistency with the client method signatures.
21855-21855: LGTM: ClientWithResponses interface signature updated correctly.The
GetCustomerAccessWithResponsemethod signature in theClientWithResponsesInterfacehas been properly updated to useULIDOrExternalKeytype, maintaining consistency with the base client interface.
21869-21869: LGTM: ClientWithResponses interface signature updated consistently.The
GetCustomerEntitlementValueWithResponsemethod signature in theClientWithResponsesInterfacehas been properly updated to useULIDOrExternalKeytype, ensuring consistency across all client interfaces.
26714-26714: LGTM: ClientWithResponses implementation signature matches interface.The
GetCustomerAccessWithResponseimplementation has been properly updated to match the interface signature change, ensuring type consistency across the client with responses implementation.
26758-26758: LGTM: ClientWithResponses implementation signature matches interface.The
GetCustomerEntitlementValueWithResponseimplementation has been properly updated to match the interface signature change, maintaining consistency across the client with responses implementation.
38847-39467: LGTM: Embedded swagger specification data updated.The embedded swagger specification data has been properly updated to reflect the API changes. Since this is a generated file, these base64 encoded changes represent the updated OpenAPI specification that now uses
ULIDOrExternalKeyinstead ofstringforcustomerIdOrKeyparameters.This indicates that the code generation process correctly incorporated the API specification changes and maintained consistency between the client code and the underlying API specification.
tothandras
force-pushed
the
fix/api-customer-id-or-key
branch
from
0ba9e73 to
292d8a3
Compare
3 participants
Fix customer key for entitlement API
Summary by CodeRabbit
New Features
Documentation
Bug Fixes