-
Notifications
You must be signed in to change notification settings - Fork 14
Signature Resource #416
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
base: main
Are you sure you want to change the base?
Signature Resource #416
Conversation
WalkthroughThis pull request includes updates to the Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
🪧 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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #416 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 50 50
Lines 1118 1120 +2
=========================================
+ Hits 1118 1120 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
|
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 (4)
tests/resources/test_signature.py (1)
8-20: Enhance test coverage with additional test cases.While the basic creation test is good, consider adding the following test cases for better coverage:
- Test with invalid
user_idformat- Test with invalid URI format
- Test with invalid IP address
- Test with invalid location format
- Test error handling scenarios
Also, consider parameterizing the test with different valid inputs to ensure the creation works with various data combinations:
@pytest.mark.parametrize( "uri,ip,location,hash", [ ("https://example.com/1.png", "192.168.1.1", "19.4326,-99.1332", "hash1"), ("https://example.com/2.jpg", "10.0.0.1", "20.4326,-98.1332", "hash2"), ], ) def test_signature_create_parametrized(uri: str, ip: str, location: str, hash: str): signature_file = SignatureFile( uri=uri, ip=ip, location=location, hash=hash, ) signature = Signature.create( user_id="USFOOBAR", signature=signature_file, ) assert signature.id assert signature.signature_idcuenca/resources/signatures.py (1)
15-24: Consider adding more comprehensive schema examples.While the current schema example is good, it could be enhanced with:
- Example values for all fields in the
SignatureFileschema- Additional example values showing different IP formats (IPv4/IPv6)
model_config = ConfigDict( json_schema_extra={ 'example': { 'id': 'string', - 'signature_id': SignatureFile.schema().get('example'), + 'signature_id': { + 'uri': 'https://example.com/signature.png', + 'ip': '192.168.1.100', # IPv4 example + 'location': '19.432608, -99.133209', + 'hash': '1234567890' + }, 'created_at': '2020-05-24T14:15:22Z', } }, json_encoders={IPv4Address: str, IPv6Address: str}, )tests/resources/cassettes/test_signature_create.yaml (2)
4-5: Use non-sensitive test data and follow security best practices.The test data contains potentially sensitive information:
- Location coordinates should use obviously fake values (e.g., "0.0, 0.0")
- IP address should use reserved test IPs (e.g., "192.0.2.0" from TEST-NET-1)
- Hash should be more realistic (e.g., use a proper SHA-256 hash)
- '{"signature": {"uri": "https://www.google.com/image.png", "location": "19.432608, - -99.133209", "ip": "192.168.1.100", "hash": "1234567890"}, "user_id": "USFOOBAR"}' + '{"signature": {"uri": "https://example.com/test.png", "location": "0.0, 0.0", + "ip": "192.0.2.1", "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"}, "user_id": "US_TEST_USER"}'
20-22: Use realistic timestamps in test data.The
created_attimestamp is set to a future date (2025). While this won't affect the tests, it's better to use a fixed past or present date for consistency and clarity.- "created_at": "2025-02-13T20:58:46Z"}' + "created_at": "2024-02-13T20:58:46Z"}'
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
cuenca/__init__.py(2 hunks)cuenca/resources/__init__.py(3 hunks)cuenca/resources/signatures.py(1 hunks)requirements.txt(1 hunks)tests/resources/cassettes/test_signature_create.yaml(1 hunks)tests/resources/test_signature.py(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- requirements.txt
🔇 Additional comments (4)
cuenca/resources/signatures.py (1)
11-14: LGTM! The class definition and resource configuration look good.The class correctly inherits from
CreatableandRetrievable, and properly defines the resource endpoint and signature_id field.cuenca/__init__.py (1)
32-32: LGTM! The Signature resource is properly exported.The changes correctly add the Signature resource to the module's public API.
Also applies to: 81-81
cuenca/resources/__init__.py (1)
31-31: LGTM! The Signature resource is properly registered.The changes correctly:
- Add Signature to
__all__- Import from
.signaturesmodule- Register in
resource_classesto avoid circular importsAlso applies to: 76-76, 118-118
tests/resources/cassettes/test_signature_create.yaml (1)
47-48: LGTM!The cassette version and structure follow VCR.py best practices.
cuenca/resources/signatures.py
Outdated
| @classmethod | ||
| def create( | ||
| cls, | ||
| signature: SignatureFile, | ||
| user_id: str, | ||
| session: Session = global_session, | ||
| ) -> 'Signature': | ||
| req = SignatureRequest(signature=signature, user_id=user_id) | ||
| return cls._create(**req.model_dump(mode='json'), session=session) |
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.
💡 Verification agent
🧩 Analysis chain
Verify error handling in create method.
The create method looks good, but let's verify how errors from the API are handled.
🏁 Script executed:
#!/bin/bash
# Description: Check error handling in base classes
# Search for error handling in base classes
rg -A 5 "_create.*session" cuenca/resources/base.pyLength of output: 53
I'll run an additional script to inspect the definition of the _create method in cuenca/resources/base.py along with surrounding context to verify if and how error handling is implemented there.
🏁 Script executed:
#!/bin/bash
# Retrieve the definition of the _create method from cuenca/resources/base.py with context to inspect error handling patterns.
rg -C20 "def _create\(" cuenca/resources/base.pyLength of output: 983
Attention Required: Review API Error Handling in create Method
The create method in cuenca/resources/signatures.py is thinly wrapping a call to the base class _create method. Our inspection of the _create implementation in cuenca/resources/base.py reveals that it directly calls:
resp = session.post(cls._resource, data)
return cls(**resp)with no explicit error handling (e.g., try/except blocks or response status checks) to manage API errors.
- Action Items:
- Verify whether the
session.postmethod internally handles API errors or if the responsibility is intentionally deferred. - Consider adding explicit error handling (e.g., try/except mechanisms or status code checks) within
_createto catch and manage error responses, ensuring that downstream code increatedeals gracefully with failures.
- Verify whether the
closes #415
Summary by CodeRabbit