Fix error object serialization in CLI push command [PRD-5048] #554
Conversation
When API returns error objects, they were being stringified as "[object Object]" instead of showing the actual error details. Changes: - Add serializeErrorResponse() helper function to both projectFullClient.ts and graphFullClient.ts - Properly serialize error objects to human-readable strings - Handle errors with code + message fields (format: "code: message") - Fall back to JSON.stringify() for complex error objects - Add rawError field to structured logs for better debugging - Support both errorJson.error and errorJson.message response formats Fixes: https://linear.app/inkeep/issue/PRD-5048/better-errors-on-push-conflicts-no-error-object-object-cli 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Claude finished @amikofalvy's task —— View job Code Review CompleteI've reviewed the error object serialization improvements in the CLI push command. Overall, this is a solid fix that addresses a real UX issue, but there are several architectural concerns and opportunities for improvement. Review Tasks:
🚨 Critical Issues1. Code Duplication (High Priority)The Recommended Solution:
// In error.ts
export function serializeErrorResponse(error: any): string {
if (typeof error === 'string') {
return error;
}
if (typeof error === 'object' && error !== null) {
// If error has code and message, format them nicely
if (error.code && error.message) {
return `${error.code}: ${error.message}`;
}
// Otherwise, stringify the whole object
return JSON.stringify(error, null, 2);
}
return String(error);
}2. Inconsistent Fetch Usage (Medium Priority)
This creates inconsistency in header handling and error behavior. Both should use 🔍 Architecture & Design Concerns3. Redundant Error Parsing Logic (Medium Priority)Lines 77-83 in
Suggested Optimization: const errorText = await response.text();
let errorMessage = `Failed to create project: ${response.status} ${response.statusText}`;
let parsedError: any;
try {
parsedError = JSON.parse(errorText);
const errorObject = parsedError.error || parsedError.message || parsedError;
errorMessage = serializeErrorResponse(errorObject);
} catch {
if (errorText) {
errorMessage = errorText;
}
parsedError = errorText;
}4. Missing Edge Case Handling (Low Priority)Current logic checks
Consider enhancing the serialization logic: if (error.code || error.message) {
return [error.code, error.message].filter(Boolean).join(': ');
}5. API Response Format Inconsistency (Low Priority)The code handles both ✅ Positive Aspects
📝 Additional Recommendations6. Type Safety EnhancementConsider creating a proper type for expected error responses: interface ApiErrorResponse {
error?: {
code: string;
message: string;
};
message?: string;
// other potential fields
}7. Consistency with Existing Error StandardsThe codebase has a sophisticated error handling system in 8. Missing ChangesetAs noted by changeset-bot, this change affects the 🎯 Priority Action Items
|
Changed serializeErrorResponse to always use JSON.stringify for objects, ensuring no error details are lost. Previously, errors with code+message fields would only show those two fields, potentially hiding other important error information.
|
Updated to remove any truncation - the error serializer now always uses |
Summary
Fixes error object serialization in the CLI
pushcommand. When the API returns error objects, they were being stringified as"[object Object]"instead of showing the actual error details.Changes
serializeErrorResponse()helper function to bothprojectFullClient.tsandgraphFullClient.ts"code: message")JSON.stringify()for complex error objectsrawErrorfield to structured logs for better debuggingerrorJson.erroranderrorJson.messageresponse formatsBefore
After
Testing
pnpm build --filter @inkeep/agents-sdkLinks
🤖 Generated with Claude Code
Co-Authored-By: Claude [email protected]