feat(api): Return a validation error when attempting to fetch future pool balances #419
Conversation
WalkthroughThe changes introduce enhanced validation for the "at" query parameter in the Changes
Assessment against linked issues
Poem
✨ 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:
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 #419 +/- ##
=======================================
Coverage 60.94% 60.95%
=======================================
Files 566 566
Lines 28828 28835 +7
=======================================
+ Hits 17568 17575 +7
Misses 10310 10310
Partials 950 950 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
internal/api/v3/handler_pools_balances_at.go (1)
44-49: Feature implementation looks good.This validation logic correctly prevents fetching pool balances for future timestamps, which aligns with the PR objective. The error message is clear, and the error is properly recorded on the span.
Consider using UTC time for the comparison to avoid potential timezone issues:
-if time.Now().Before(at) { +if time.Now().UTC().Before(at) {internal/api/v3/handler_pools_balances_at_test.go (1)
53-59: Test case covers the new validation logic well.This test appropriately verifies that requests with a future timestamp are rejected with a 400 Bad Request status code. The test creates a timestamp one minute in the future, which is a good test case.
Consider enhancing the test to also verify the specific error message content:
handlerFn(w, req) - assertExpectedResponse(w.Result(), http.StatusBadRequest, ErrValidation) + resp := w.Result() + body := readResponseBody(resp) + assertExpectedResponse(resp, http.StatusBadRequest, ErrValidation) + Expect(body).To(ContainSubstring("cannot be in the future"))Assuming there's a helper function like
readResponseBodyto extract the response body as string.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
internal/api/v3/handler_pools_balances_at.go(3 hunks)internal/api/v3/handler_pools_balances_at_test.go(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
internal/api/v3/handler_pools_balances_at.go (1)
internal/otel/otel.go (1)
RecordError(26-29)
🔇 Additional comments (2)
internal/api/v3/handler_pools_balances_at.go (2)
4-4: Import addition looks good.Adding the fmt package is appropriate for the updated error formatting approach using fmt.Errorf.
32-35: Good improvement to error handling.Switching from errors.New to fmt.Errorf provides better error message formatting capabilities. The addition of otel.RecordError properly records the error on the tracing span, which is a good practice for observability.
Fixes: PMNT-92