Release/0.11.8 #13
Release/0.11.8 #13
Conversation
* fix(fetchOffers): process server errors with code 500-599 * feat(fetchOffers): add retrying if error >500 * fix(fetchOffers): replace to native doWithReties * add(error.utils): add getErrorFunction to extend error message
…ackage.json and package-lock.json (#520)
WalkthroughThe changes introduce a new utility for standardized error message extraction and handling, update the retry and error handling logic in the offer-fetching service to use this utility, and update package versions in the project configuration. No exported or public API signatures were altered. Changes
Poem
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
npm error Exit handler never called! ✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
![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
🧹 Nitpick comments (1)
src/error.utils.ts (1)
8-9: Improve type guard robustness.The type guard checks for the presence of the
responseproperty but doesn't validate its structure. Consider adding more specific validation for better type safety.-const isApiError = (error: unknown): error is ApiErrorResponse => - error !== null && typeof error === 'object' && 'response' in error; +const isApiError = (error: unknown): error is ApiErrorResponse => + error !== null && + typeof error === 'object' && + 'response' in error && + (error.response === undefined || typeof error.response === 'object');
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (3)
package.json(2 hunks)src/error.utils.ts(1 hunks)src/services/fetchOffers.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/error.utils.ts (1)
src/printer.ts (1)
error(25-27)
🔇 Additional comments (7)
src/error.utils.ts (2)
1-6: Well-structured error response interface.The
ApiErrorResponseinterface properly defines the expected shape of API error responses with optional properties, which is appropriate for handling various error formats.
11-29: Robust error message extraction logic.The function handles multiple error scenarios appropriately:
- Non-API errors gracefully fall back to base message
- Server errors (≥500) are properly identified and formatted
- Client errors extract the first available error message
- Proper fallback to base message when no specific error is available
The implementation is clean and follows good error handling practices.
package.json (2)
3-3: Version bump from 0.11.6 to 0.11.8 noted.The version jump skips 0.11.7. Ensure this is intentional and aligns with your release strategy.
39-39: Verify SDK compatibility and changelogI wasn’t able to find any official release notes or a CHANGELOG.md in the SDK repo (git://github.com/Super-Protocol/sdk-js.git) for versions 3.11.6 through 3.11.12. To ensure this upgrade causes no regressions:
- Inspect the SDK’s GitHub tags/commit history from v3.11.4 → v3.11.12 for breaking changes.
- Confirm that any new or changed methods still align with our current usage.
- If the repo doesn’t document these changes, reach out to the maintainers for clarification.
src/services/fetchOffers.ts (3)
6-7: Good addition of retry and error handling utilities.The new imports properly integrate the retry mechanism and centralized error handling, improving code maintainability and robustness.
59-72: Excellent integration of retry mechanism.The
doWithRetrieswrapper around the SDK call adds resilience for transient failures while maintaining the same API call structure. This improves the reliability of offer fetching operations.
78-80: Improved error handling with centralized utility.The refactored error handling:
- Uses
unknowntyping for better type safety- Leverages the centralized
getErrorMessageutility for consistent error formatting- Maintains the same error propagation pattern with
ErrorWithCustomMessageThis change improves code consistency and maintainability across the codebase.
Summary by CodeRabbit
Chores
New Features
Bug Fixes