-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(test): add e2e tests for moderation #254
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #254 +/- ##
========================================
Coverage 70.95% 70.95%
========================================
Files 35 35
Lines 8997 8997
Branches 523 523
========================================
Hits 6384 6384
Misses 2611 2611
Partials 2 2 ☔ View full report in Codecov by Sentry. |
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. 🔧 eslint
error @permaweb/aoconnect@0.0.57: The engine "yarn" is incompatible with this module. Expected version "please-use-npm". Got "1.22.22" 📝 WalkthroughWalkthroughThe pull request introduces new moderation endpoints to the AR.IO Gateway OpenAPI specification and adds corresponding end-to-end tests for these features. Specifically, two new administrative PUT endpoints are added for blocking and unblocking ARNS names: Changes
Sequence DiagramsequenceDiagram
participant Client
participant Gateway
participant AuthService
Client->>Gateway: PUT /ar-io/admin/block-name
Gateway->>AuthService: Validate API Key
alt Valid API Key
Gateway->>Gateway: Block ARNS Name
Gateway-->>Client: 200 OK
else Invalid API Key
Gateway-->>Client: 401 Unauthorized
end
Client->>Gateway: PUT /ar-io/admin/unblock-name
Gateway->>AuthService: Validate API Key
alt Valid API Key
Gateway->>Gateway: Unblock ARNS Name
Gateway-->>Client: 200 OK
else Invalid API Key
Gateway-->>Client: 401 Unauthorized
end
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
test/end-to-end/moderation.test.ts (1)
84-107
: Add test coverage for already-blocked scenarios.Currently, the test checks a straightforward block scenario and then verifies the resource returns 404 when blocked. Consider adding a test for when an ARNS name is already blocked, to confirm that blocking it again doesn’t produce unwanted side effects.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
docs/openapi.yaml
(1 hunks)test/end-to-end/moderation.test.ts
(1 hunks)
🔇 Additional comments (5)
test/end-to-end/moderation.test.ts (4)
39-40
: Test suite is well-structured.
The top-level “Moderation” describe block effectively organizes the E2E tests, providing clarity on what’s being tested for administrative blocking features.
64-83
: Good use of 401 checks to verify authorization.
This section thoroughly tests for unauthorized access, ensuring that the correct error code is returned when an invalid API key is presented. This is critical for security and correctness.
120-149
: Verification of final unblocked state is solid.
The flow of re-blocking the name before unblocking it ensures the test environment is well-controlled. Good job verifying a 200 after unblocking.
152-200
: Consider verifying “unblock transaction” behavior.
While blocking a transaction in this suite is correct, it might be beneficial to provide a similar test for unblocking a transaction, if such functionality exists or is planned.
Do you want me to open a new GitHub issue to track adding an “unblock transaction” endpoint and tests if that functionality is needed?
docs/openapi.yaml (1)
776-805
: Consistency with code usage verified.
The /ar-io/admin/block-name
endpoint’s request body fields match the tested keys in “moderation.test.ts”, ensuring the specification is accurately aligned with the actual implementation.
'/ar-io/admin/unblock-name': | ||
put: | ||
tags: [Admin] | ||
summary: Unblock an ARNS name. | ||
description: Unblock an ARNS name so your AR.IO Gateway will serve it again. | ||
operationId: adminUnblockName | ||
requestBody: | ||
required: true | ||
content: | ||
application/json: | ||
schema: | ||
type: object | ||
properties: | ||
name: | ||
type: string | ||
description: The name you want to unblock. | ||
responses: | ||
'200': | ||
description: Successful operation. | ||
'401': | ||
description: Unauthorized, API key likely incorrect. | ||
security: | ||
- bearerAuth: [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add 400 or 404 specification for missing or unknown ARNS name.
Currently, the specification includes 200 and 401 responses. Consider defining a 400 or 404 response to cover scenarios where the requested name does not exist or is invalid.
No description provided.