refactor: centralize API error handling in ky client #135
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 centralizes API error handling logic by implementing a
beforeErrorhook directly in the ky HTTP client. Previously, every API method had to manually wrap calls and invokeformatApiError. Now, all API errors are automatically caught and formatted by the base client, eliminating boilerplate and ensuring consistent error handling across the codebase.Related Issue
Addresses refactoring discussed in #112: #112 (comment)
Type of Change
Changes Made
formatApiErrorfunction to be internal withinbase44-client.ts(no longer exported)handleApiErrorshook using ky'sbeforeErrormechanism to automatically format all API errorsbase44Clientconfiguration to include the new error handling hookformatApiErrorexport fromindex.tsagent/api.tsby removing manual error handling andthrowHttpErrors: falseflagsentity/api.tsby removing manual error handling while preserving special 428 status code logictests/core/errors.test.tsasformatApiErroris now an internal implementation detailTesting
npm test)Checklist
Additional Notes
This refactoring reduces boilerplate code by 13 net lines (83 additions, 96 deletions) while improving maintainability. The error handling behavior remains functionally identical from the consumer's perspective - all API errors are still caught and formatted into readable error messages. The 428 status code special handling in
syncEntitiesis preserved using ky'sHTTPErrortype.🤖 Generated by Claude | 2026-01-27 21:45 UTC