feat: add permissions for ratelimit overrides #2126
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
📝 Walkthrough📝 WalkthroughWalkthroughThe changes in this pull request primarily enhance the rate limiting functionality across various components of the application. Key modifications include the addition of new route handlers for managing rate limit overrides, updates to permissions related to rate limits, and adjustments to logging events. The import paths for certain modules have been corrected, and several tests have been added or modified to ensure proper functionality and error handling for the new rate limit features. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant API
participant Database
participant Logger
User->>API: Request to set rate limit override
API->>Database: Validate namespace and identifier
Database-->>API: Return validation result
alt If valid
API->>Database: Create or update override
Database-->>API: Return override details
API->>Logger: Log override action
Logger-->>API: Confirm log entry
API-->>User: Respond with success
else If invalid
API-->>User: Respond with error
end
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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! 🙏 |
…-custom-override-permissions
….com/unkeyed/unkey into eng-1336-custom-override-permissions
![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
🧹 Outside diff range and nitpick comments (2)
.github/workflows/pr.yaml (2)
11-26: LGTM with suggestions for robustness.The new
test_unitjob structure is clean and follows good practices. However, consider these enhancements for better reliability and visibility:test_unit: name: Unit Test runs-on: ubuntu-latest + timeout-minutes: 15 steps: - uses: actions/checkout@v4 - name: Install uses: ./.github/actions/install with: ts: true - name: Build uses: ./.github/workflows/build.yaml - name: Test run: pnpm test + env: + CI: true + + - name: Upload test results + if: always() + uses: actions/upload-artifact@v3 + with: + name: test-results + path: | + coverage/ + junit.xml
23-23: Consider using an action instead of a workflow for the build step.Using a workflow file (
.github/workflows/build.yaml) as a dependency might cause maintenance issues. Workflows are typically triggered by events, while actions are designed for reuse as steps.Consider converting the build workflow into a composite action at
.github/actions/buildfor better maintainability and clearer dependency management.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
.github/workflows/pr.yaml(1 hunks).github/workflows/unit_test.yaml(0 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/unit_test.yaml
🔇 Additional comments (1)
.github/workflows/pr.yaml (1)
25-26: Verify test coverage for rate limit permissions.
Since this PR introduces new permissions for rate limit overrides, ensure that the test command provides adequate coverage for permission-related functionality.
✅ Verification successful
Let me gather more information about the test coverage and implementation details.
Let me check the actual test implementations for rate limit and permission-related tests.
Based on the test files analysis, I can now provide a final response:
Test coverage for rate limit permissions is comprehensive
The test suite includes extensive coverage for rate limit permissions and functionality:
- Security tests for rate limit permissions (create, read, update, delete)
- Happy path tests for rate limit operations
- Error handling tests for rate limit operations
- Accuracy tests for rate limit enforcement
- Integration tests for rate limit verification
- Tests for rate limit overrides and configurations
Key test files:
v1_ratelimits_*.test.tsfiles cover all CRUD operationsv1_keys_verifyKey.ratelimit_accuracy.test.tsverifies rate limiting accuracyv1_ratelimits_limit.accuracy.test.tstests limit enforcementv1_ratelimits_limit.overrides.test.tsvalidates override functionality
The test command pnpm test runs all these tests with proper configuration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for permission-related test files and their coverage
# Look for test files related to permissions and rate limits
echo "=== Searching for relevant test files ==="
rg -l "permission.*test|ratelimit.*test" -g "*.{ts,tsx,js,jsx}"
# Check if there are any permission-related tests in the test command configuration
echo -e "\n=== Checking test configuration ==="
fd -e json "jest.config|vitest.config" -x cat {}
Length of output: 886
Script:
#!/bin/bash
# Check the actual test implementations for rate limit permissions
echo "=== Checking rate limit permission test implementations ==="
rg "rate.*limit.*permission" -A 5 -B 5
# Check for rate limit permission-related code
echo -e "\n=== Checking rate limit permission implementations ==="
ast-grep --pattern 'function $FUNC($$$) {
$$$
rateLimit
$$$
}'
# Check test scripts in package.json
echo -e "\n=== Checking test scripts in package.json ==="
fd "package.json" -x cat {}
Length of output: 36268
Script:
#!/bin/bash
# Check the content of permission and rate limit test files
echo "=== Checking permission test implementations ==="
rg -A 10 "describe|it\(" apps/api/src/routes/v1_permissions_*.test.ts
echo -e "\n=== Checking rate limit test files ==="
rg -l "ratelimit" -g "*.test.{ts,tsx,js,jsx}"
echo -e "\n=== Checking rate limit test implementations ==="
rg -A 10 "describe|it\(" $(rg -l "ratelimit" -g "*.test.{ts,tsx,js,jsx}")
Length of output: 191820
….com/unkeyed/unkey into eng-1336-custom-override-permissions
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
apps/api/src/routes/v1_keys_getVerifications.ts (1)
243-246: Consider enriching the response with error informationWhile the error handling improvement is good, consider enriching the response to include information about which keys failed to retrieve data. This would help clients understand if they're receiving partial data.
Here's a suggested implementation:
export type V1KeysGetVerificationsResponse = z.infer< (typeof route.responses)[200]["content"]["application/json"]["schema"] >; +type VerificationError = { + keyId: string; + error: string; +}; // Update the response schema const route = createRoute({ // ... other config responses: { content: { "application/json": { schema: z.object({ verifications: z.array(/* existing schema */), + errors: z.array(z.object({ + keyId: z.string(), + error: z.string(), + })).optional(), }), }, }, }, }, }); // In the route handler const errors: VerificationError[] = []; const verificationsFromAllKeys = await Promise.all( ids.map(({ keyId, keySpaceId }) => { // ... existing code }), ); for (const [index, dataPoint] of verificationsFromAllKeys.entries()) { if (dataPoint.err) { logger.error(dataPoint.err.message); + errors.push({ + keyId: ids[index].keyId, + error: dataPoint.err.message, + }); continue; } // ... existing code } return c.json({ verifications: Object.entries(verifications).map(/* existing code */), + errors: errors.length > 0 ? errors : undefined, });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
apps/api/src/routes/v1_keys_getVerifications.ts(2 hunks)
🔇 Additional comments (1)
apps/api/src/routes/v1_keys_getVerifications.ts (1)
83-83: LGTM: Logger service extraction
The addition of the logger service follows the established pattern of service extraction.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fixes # (issue)
eng-1336
Type of change
How should this be tested?
Check if I understood the assignment properly.
Checklist
Required
pnpm buildpnpm fmtconsole.logsgit pull origin mainAppreciated
Summary by CodeRabbit
New Features
CreateKeycomponent to improve form handling and UI interactions.Bug Fixes
Tests
Chores