Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
📝 WalkthroughWalkthroughThree new files are introduced in the Changes
Sequence Diagram(s)sequenceDiagram
participant k6_Script as k6 Script (ratelimit.js / keyverify.js)
participant API_v1 as API v1 Endpoint
participant API_v2 as API v2 Endpoint
loop For each test iteration
k6_Script->>k6_Script: Randomly select API version (v1 or v2)
alt v1 selected
k6_Script->>API_v1: POST request with payload and headers
else v2 selected
k6_Script->>API_v2: POST request with payload and headers
end
API_v1-->>k6_Script: Response (status, latency)
API_v2-->>k6_Script: Response (status, latency)
k6_Script->>k6_Script: Record latency metric and check status
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested reviewers
✨ Finishing Touches
🧪 Generate unit tests
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 (
|
|
Thank you for following the naming conventions for pull request titles! 🙏 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
go/benchmarks/README.md(1 hunks)go/benchmarks/keyverify.js(1 hunks)go/benchmarks/ratelimit.js(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: chronark
PR: unkeyed/unkey#3474
File: go/apps/api/routes/v2_keys_verify_key/200_test.go:380-380
Timestamp: 2025-07-14T08:15:56.747Z
Learning: In the Unkey codebase, there is a mechanism to set the server's time via a header for test control, which helps make ratelimit tests deterministic instead of time-dependent. This is useful for preventing flaky tests where the second request might hit a new ratelimit window.
go/benchmarks/README.md (2)
Learnt from: chronark
PR: #3474
File: go/apps/api/routes/v2_keys_verify_key/200_test.go:380-380
Timestamp: 2025-07-14T08:15:56.747Z
Learning: In the Unkey codebase, there is a mechanism to set the server's time via a header for test control, which helps make ratelimit tests deterministic instead of time-dependent. This is useful for preventing flaky tests where the second request might hit a new ratelimit window.
Learnt from: CR
PR: unkeyed/unkey#0
File: go/deploy/CLAUDE.md:0-0
Timestamp: 2025-07-21T18:05:58.236Z
Learning: Applies to go/deploy/**/*.{go,js,ts,tsx,py,sh,md,txt,json,yaml,yml,ini,env,conf,html,css,scss,xml,c,h,cpp,java,rb,rs,php,pl,sql} : Make sure to add relevant anchor comments whenever a file or piece of code is too complex, very important, confusing, or could have a bug.
go/benchmarks/keyverify.js (6)
Learnt from: chronark
PR: #3474
File: go/apps/api/routes/v2_keys_verify_key/200_test.go:380-380
Timestamp: 2025-07-14T08:15:56.747Z
Learning: In the Unkey codebase, there is a mechanism to set the server's time via a header for test control, which helps make ratelimit tests deterministic instead of time-dependent. This is useful for preventing flaky tests where the second request might hit a new ratelimit window.
Learnt from: MichaelUnkey
PR: #2114
File: apps/api/src/routes/v1_keys_updateKey.error.test.ts:0-0
Timestamp: 2024-09-27T15:20:05.475Z
Learning: In the v1/keys.updateKey endpoint, the server validates the refill configuration before checking if the key exists. Therefore, tests can assert validation errors without needing to create the key first.
Learnt from: Flo4604
PR: #2955
File: go/apps/api/routes/v2_identities_create_identity/handler.go:162-202
Timestamp: 2025-03-19T09:25:59.751Z
Learning: In the Unkey codebase, input validation for API endpoints is primarily handled through OpenAPI schema validation, which occurs before requests reach the handler code. For example, in the identities.createIdentity endpoint, minimum values for ratelimit duration and limit are defined in the OpenAPI schema rather than duplicating these checks in the handler.
Learnt from: ogzhanolguncu
PR: #3242
File: apps/dashboard/app/(app)/apis/[apiId]/keys/[keyAuthId]/[keyId]/components/table/hooks/use-logs-query.ts:228-231
Timestamp: 2025-05-15T16:21:50.911Z
Learning: The codebase for Unkey allows the use of modern JavaScript features like Array.prototype.toSorted() even though they may not be supported in all browsers.
Learnt from: ogzhanolguncu
PR: #3292
File: apps/dashboard/lib/trpc/routers/key/create.ts:11-14
Timestamp: 2025-06-02T11:09:58.791Z
Learning: In the unkey codebase, TypeScript and the env() function implementation already provide sufficient validation for environment variables, so additional runtime error handling for missing env vars is not needed.
Learnt from: chronark
PR: #3617
File: go/apps/api/openapi/openapi.yaml:3309-3312
Timestamp: 2025-07-16T17:51:57.297Z
Learning: In the Unkey API OpenAPI schema, the permissions query regex for the verifyKey endpoint intentionally allows all whitespace characters (including tabs and newlines) via \s. Do not flag this as an error in future reviews.
go/benchmarks/ratelimit.js (3)
Learnt from: chronark
PR: #2544
File: apps/api/src/pkg/env.ts:4-6
Timestamp: 2024-10-23T12:05:31.121Z
Learning: The cloudflareRatelimiter type definition in apps/api/src/pkg/env.ts should not have its interface changed; it should keep the limit method returning Promise<{ success: boolean }> without additional error properties.
Learnt from: chronark
PR: #2544
File: apps/api/src/pkg/ratelimit/client.ts:83-83
Timestamp: 2024-10-23T12:04:12.530Z
Learning: In the metrics.emit call, it's acceptable to set mode to "cloudflare" when using Cloudflare's rate limiter.
Learnt from: chronark
PR: #3474
File: go/apps/api/routes/v2_keys_verify_key/200_test.go:380-380
Timestamp: 2025-07-14T08:15:56.747Z
Learning: In the Unkey codebase, there is a mechanism to set the server's time via a header for test control, which helps make ratelimit tests deterministic instead of time-dependent. This is useful for preventing flaky tests where the second request might hit a new ratelimit window.
🪛 markdownlint-cli2 (0.17.2)
go/benchmarks/README.md
7-7: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
15-15: Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
19-19: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
27-27: Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
30-30: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
31-31: Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
35-35: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
36-36: Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
39-39: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
40-40: Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
45-45: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
46-46: Lists should be surrounded by blank lines
(MD032, blanks-around-lists)
⏰ 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). (6)
- GitHub Check: Test Agent Local / test_agent_local
- GitHub Check: Test Go API Local / Test
- GitHub Check: Build / Build
- GitHub Check: Test API / API Test Local
- GitHub Check: Test Packages / Test
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (8)
go/benchmarks/README.md (2)
1-49: LGTM! Comprehensive documentation for the benchmark suite.The documentation provides clear setup instructions, usage examples, and configuration details for both benchmark scripts. The structure is logical and covers all necessary information for users to run the benchmarks effectively.
16-17: Endpoints Confirmed: README.md Matches Benchmark ScriptsThe benchmark script at
go/benchmarks/ratelimit.jsindeed calls:
/v1/ratelimits.limit(plural) onapi.unkey.dev/v2/ratelimit.limit(singular) onapi.unkey.comNo updates to
go/benchmarks/README.mdare necessary.go/benchmarks/keyverify.js (3)
22-29: LGTM! Elegant load zone distribution logic.The dynamic percentage calculation ensures even distribution across active load zones, with proper handling of remainder percentages for the last zone.
48-54: LGTM! Proper environment variable validation.Clear error messages and early validation prevent runtime issues during test execution.
67-79: LGTM! Well-implemented API version randomization.The 50/50 split between v1 and v2 APIs is correctly implemented with proper request tagging for metrics collection.
go/benchmarks/ratelimit.js (3)
46-46: Good addition of REGION parameter.The region parameter provides useful tagging for metrics analysis, though it's not used in keyverify.js for consistency.
70-87: LGTM! Well-structured rate limiting benchmark logic.The random user identifier selection and API version randomization provide good test coverage. The request payload structure is appropriate for rate limiting testing.
70-87: Naming difference is intentional—no changes needed.Verified that the v2 route is defined as
/v2/ratelimit.limitingo/apps/api/routes/register.go, its handler’sPath()method, and OpenAPI specs, while the v1 endpoint remains/v1/ratelimits.limitas used in benchmarks. The mismatch is intentional and aligns with existing API definitions.
1 participant
What does this PR do?
Add k6 load testing scripts for benchmarking v1 and v2 Unkey APIs. The PR includes two benchmark scripts:
ratelimit.js- Tests ratelimiting endpoints with random identifierskeyverify.js- Tests key verification endpointsBoth scripts compare performance between v1 (
api.unkey.dev) and v2 (api.unkey.com) APIs with a 50/50 traffic split.Fixes # (issue)
Type of change
How should this be tested?
UNKEY_ROOT_KEY=your_key REGION=us-east k6 cloud ratelimit.jsUNKEY_ROOT_KEY=your_key KEY=your_test_key k6 cloud keyverify.jsChecklist
Required
pnpm buildpnpm fmtconsole.logsgit pull origin mainAppreciated
Summary by CodeRabbit