Refactor API error handling to unify 422 error response types

[jfrench9]

Summary

Refactors error handling across 54 API operation modules in the robosystems_client to standardize how HTTP error responses (particularly 422 Unprocessable Entity) are processed and returned. This change unifies the response type handling pattern across all API operations in the client library.

Key Accomplishments

• Unified error response handling: Standardized the pattern for handling API error responses across all operation modules, eliminating inconsistencies in how errors (especially 422 responses) were parsed and returned.
• Reduced code complexity: Simplified error handling logic across all affected modules, as evidenced by the net reduction in lines of code across the board (most files show more deletions than additions).
• Comprehensive coverage: Applied the fix consistently across all API surface areas:
  • Connections (sync_connection.py)
  • Robo Investor extensions (CRUD operations for portfolio blocks and securities)
  • Robo Ledger extensions (30+ operations covering agents, event blocks, event handlers, information blocks, taxonomy blocks, journal entries, publish lists, reports, mapping associations, periods, and more)
  • Graph operations (tier changes, backups, subgraphs, deletions, materialization, restoration)
  • Graph creation (create_graph.py)

Breaking Changes

• Potential breaking change: Consumers of this client library that explicitly handle or type-check error response objects may need to be updated if the response type for error cases (e.g., 422) has changed. Any code that relies on the previous error response structure should be reviewed and adjusted accordingly.

Testing Notes

• Verify that all API operations correctly return the unified error response type when the server responds with 422 and other error status codes.
• Validate that successful response paths (2xx) remain unaffected by the refactor.
• Test edge cases around validation errors to ensure error details/messages are properly propagated through the new unified response type.
• Integration tests against live or mocked API endpoints should confirm that deserialization of error responses works correctly across all affected operations.

Infrastructure Considerations

• This is a client-side library change only; no server-side or infrastructure modifications are required.
• Any CI/CD pipelines running client integration tests should be monitored for regressions after this change is merged.
• Downstream services or applications consuming this client library should be tested for compatibility with the updated error response types before upgrading.

---

🤖 Generated with Claude Code

Branch Info:

• Source: chore/422-error-resp-fix
• Target: main
• Type: feature

Co-Authored-By: Claude noreply@anthropic.com