-
Notifications
You must be signed in to change notification settings - Fork 114
fix: error handling at storage level #609
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
Conversation
WalkthroughThe pull request introduces significant changes to multiple files in the Changes
Possibly related PRs
Suggested reviewers
Poem
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: 0
🧹 Outside diff range and nitpick comments (2)
internal/storage/ledger/transactions.go (2)
Line range hint
53-242
: LGTM! Error handling improvements look good.The changes to return
(*bun.SelectQuery, error)
instead of usingret.Err(err)
improve error handling by making it more explicit and consistent with Go's error handling patterns. The error propagation is now clearer and follows the standard Go practice of returning errors alongside results.Consider adding error wrapping to provide more context about where the error occurred. For example:
- return nil, err + return nil, fmt.Errorf("validating query: %w", err)
375-384
: LGTM! Consider enhancing error context.The error handling for
selectTransactions
is properly implemented. However, the subsequent database operation's error handling could be improved by adding more context.Consider wrapping the database error with additional context:
if err := selectTransactions. Where("transactions.id = ?", filter.ID). Limit(1). Model(ret). Scan(ctx); err != nil { - return nil, postgres.ResolveError(err) + return nil, fmt.Errorf("scanning transaction: %w", postgres.ResolveError(err)) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
internal/storage/ledger/accounts.go
(10 hunks)internal/storage/ledger/balances.go
(4 hunks)internal/storage/ledger/moves.go
(3 hunks)internal/storage/ledger/transactions.go
(7 hunks)internal/storage/ledger/volumes.go
(6 hunks)
🔇 Additional comments (30)
internal/storage/ledger/balances.go (9)
Line range hint 21-154
: Improved Error Handling in selectAccountWithAssetAndVolumes
The function selectAccountWithAssetAndVolumes
now returns an error alongside the query. This enhancement allows for proper error propagation and handling throughout the call stack, increasing the robustness of the code.
55-55
: Proper Error Propagation of Query Building Errors
Returning nil, err
ensures that any errors encountered during query construction are correctly propagated to the caller.
60-60
: Correct Feature Flag Check for Address Segments
The check for FeatureIndexAddressSegments
and the corresponding error return maintain feature gating and prevent unintended usage when the feature is disabled.
67-68
: Appropriate Error Handling for Missing Moves History Feature
By returning an error when FeatureMovesHistory
is not enabled, the code prevents execution of dependent logic, which is essential for maintaining system integrity.
69-71
: Handling Errors from SelectDistinctMovesBySeq
The code correctly captures and propagates errors returned by SelectDistinctMovesBySeq
, ensuring that any issues are not silently ignored.
149-149
: Enhanced Error Context with Error Wrapping
Using fmt.Errorf("building where clause: %w", err)
provides additional context for the error, which aids in debugging and log analysis.
154-154
: Consistent Return Statement in selectAccountWithAssetAndVolumes
The function concludes with return finalQuery, nil
, adhering to the expected return types and ensuring clarity in successful execution paths.
157-166
: Updated Error Handling in selectAccountWithAggregatedVolumes
The function now returns an error together with the query, and properly handles errors from selectAccountWithAssetAndVolumes
. This change enhances consistency and reliability.
191-194
: Proper Error Handling in GetAggregatedBalances
Errors from SelectAggregatedBalances
are now correctly handled, allowing the function to appropriately respond to issues during data retrieval.
internal/storage/ledger/accounts.go (10)
45-58
: Improved Error Handling in selectBalance
The function now returns an error along with the query. Errors from SelectDistinctMovesBySeq
are properly checked and propagated, enhancing the function's robustness.
Line range hint 82-232
: Enhanced Error Propagation in selectAccounts
By adjusting the return type to include an error, selectAccounts
now properly propagates errors from internal calls like selectBalance
and selectAccountWithAggregatedVolumes
, which improves overall error handling in account queries.
111-111
: Detailed Error Messaging in Filter Validation
The error message fmt.Errorf("failed to check filters: %w", err)
adds clarity to filter validation failures, aiding in troubleshooting.
138-144
: Correct Error Handling When Fetching Aggregated Volumes
Errors from selectAccountWithAggregatedVolumes
are now properly handled, ensuring that the function reacts appropriately to issues during data aggregation.
171-175
: Error Propagation in Dynamic Query Construction
The function now checks and returns errors from selectBalance
when building dynamic queries, which is crucial for preventing silent failures during query execution.
223-223
: Consistent Error Handling in Filter Evaluation
By returning an error with context fmt.Errorf("evaluating filters: %w", err)
, the code ensures consistent error propagation and easier debugging.
232-232
: Consistent Success Return in selectAccounts
The function ends with return ret, nil
, which clearly indicates successful execution without errors.
236-244
: Error Handling in ListAccounts
Function
The ListAccounts
function now properly handles errors returned by selectAccounts
, ensuring that any issues are communicated to the caller.
274-278
: Proper Error Checking in GetAccount
Errors from selectAccounts
are appropriately handled, allowing GetAccount
to respond correctly to failures in account retrieval.
298-306
: Error Propagation in CountAccounts
The function correctly handles errors from selectAccounts
, maintaining consistency in error management across account-related functions.
internal/storage/ledger/moves.go (3)
Line range hint 15-31
: Adjusted Return Type in SortMovesBySeq
for Error Handling
The function now returns an error along with the query. This change allows for proper error propagation, especially when the required feature is not enabled.
34-38
: Error Handling in SelectDistinctMovesBySeq
Errors from SortMovesBySeq
are now correctly handled and propagated, ensuring that upstream functions are aware of and can handle any issues.
50-50
: Consistent Return Statement in SelectDistinctMovesBySeq
Returning ret, nil
maintains consistency in the success path, clearly indicating that the function executed without errors.
internal/storage/ledger/volumes.go (6)
Line range hint 67-235
: Improved Error Handling in selectVolumes
Function
The function selectVolumes
now returns an error along with the query. This enhancement ensures that any issues during query construction are properly communicated to the caller.
101-101
: Consistent Error Propagation in Query Building
By returning nil, err
, the function ensures that errors encountered during query building are correctly propagated, aligning with Go error-handling best practices.
118-118
: Feature Flag Verification for Move History
The check for FeatureMovesHistory
with an appropriate error return prevents the use of move history features when they are not enabled.
213-213
: Error Handling During Filter Parsing
Errors encountered while parsing filters are properly returned, which improves the reliability of query executions.
235-235
: Consistent Return Statement in selectVolumes
The function concludes with return globalQuery, nil
, providing clarity on the successful execution path.
245-254
: Error Handling in GetVolumesWithBalances
Errors from selectVolumes
are now correctly handled in GetVolumesWithBalances
, ensuring that any issues in volume retrieval are properly communicated.
internal/storage/ledger/transactions.go (2)
320-328
: LGTM! Proper error handling from selectTransactions.
The error handling is properly implemented, checking and propagating errors from the selectTransactions
call before proceeding with cursor creation.
350-358
: LGTM! Proper error handling from selectTransactions.
The error handling is properly implemented, checking and propagating errors from the selectTransactions
call before proceeding with the count query.
No description provided.