refactor: centralize API error handling in ky client#135
Merged
Conversation
Contributor
🚀 Package Preview Available!Install this PR's preview build with npm: npm i @base44-preview/cli@0.0.25-pr.135.55d3e79Prefer not to change any import paths? Install using npm alias so your code still imports npm i "base44@npm:@base44-preview/cli@0.0.25-pr.135.55d3e79"Or add it to your {
"dependencies": {
"base44": "npm:@base44-preview/cli@0.0.25-pr.135.55d3e79"
}
}
Preview published to npm registry — try new features instantly! |
This was referenced Jan 31, 2026
This commit moves API error handling logic directly into the base ky client using the beforeError hook, eliminating the need to manually call formatApiError in every API method. Changes: - Made formatApiError internal to base44-client.ts - Added handleApiErrors hook using ky's beforeError mechanism - Updated base44Client to include error handling in beforeError hooks - Removed formatApiError export from index.ts - Simplified agent/api.ts by removing manual error handling - Simplified entity/api.ts by removing manual error handling - Preserved 428 status code handling in syncEntities - Removed tests/core/errors.test.ts as formatApiError is now internal Benefits: - Reduces boilerplate in API client methods - Ensures consistent error handling across all API calls - Centralizes error formatting logic - Makes the codebase easier to maintain Co-authored-by: paveltarno <Paveltarno@users.noreply.github.com>
0253932 to
07d5d9b
Compare
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR refactors API error handling by introducing a centralized
ApiError.fromHttpError()method that converts HTTP client errors into structuredApiErrorinstances. Previously, API methods used inconsistent patterns for error handling. Now, all API calls use a standardized try-catch pattern withApiError.fromHttpError(), which automatically extracts status codes, formats error messages from response bodies, and adds contextual information about which operation failed.Related Issue
Addresses refactoring discussed in #112: #112 (comment)
Type of Change
Changes Made
ApiError.fromHttpError()static method insrc/core/errors.tsto convert HTTP errors to ApiError with contextformatApiError()function fromsrc/core/clients/base44-client.tstosrc/core/errors.ts(now internal)HttpErrorLikeinterface andisHttpError()type guard for safe error parsingformatApiErrorand API error types fromsrc/core/clients/index.tsexportsagent/api.ts,entity/api.ts,function/api.ts,project/api.ts, andsite/api.tsto use try-catch withApiError.fromHttpError()entity/api.tsusing ky'sHTTPErrortypeApiErrorResponseSchemanaming inschemas.tsfor clarityTesting
npm test)Checklist
Additional Notes
This refactoring improves error handling consistency across all API operations while maintaining identical functionality from the consumer's perspective. The new
ApiError.fromHttpError()method provides better error context by including the operation name in error messages (e.g., "Error syncing agents" instead of generic error messages). The change reduces code duplication and makes it easier to maintain consistent error handling patterns as new API methods are added.🤖 Generated by Claude | 2026-02-01 00:00 UTC