-
Notifications
You must be signed in to change notification settings - Fork 3
Open
Labels
ready_for_releaseIssue has been completed, but the resolution has not been pushed out to a release.Issue has been completed, but the resolution has not been pushed out to a release.
Description
When handling errors for request/command messages, the current approach we have with error handling is this:
pydantic.ValidationErrorexceptions are captured by the INTERSECT-SDK, and their associated error messages are sent through INTERSECT (with thehas_error=Trueflag)- do not catch
BaseExceptionexceptions, because these are generally not intended to be caught - all other exceptions, whether deliberately thrown or uncaught, are caught by the INTERSECT-SDK and then logged on the server, but the response message will simply say something generic like "Server messed up". This is important because some exceptions could leak sensitive information.
We want to keep all of this behavior, but want to add an additional functionality:
- if the Service throws a specific
IntersectUserException, send the error message in the response message. This allows for clients to be informed of what went wrong, without having to rely on all bubbled-up exceptions going through Pydantic; for example, if a user is trying to get data from a service-managed database and submits a database ID with the correct format, but the database does not have an entry with this ID, an IntersectUserException should realistically be raised at this point.
IntersectUserException itself should always have a consistent structure. Note that it should only be raised if the submitted data was somehow incorrect; if the server messed up, IntersectUserException should not be raised.
For the current implementation of IntersectUserException
- just require some sort of descriptive string message passed through
For future implementations of IntersectUserException
- it may make sense to require other fields on the Exception (i.e. a numerical code)
- more advanced implementations could even have an error schema per endpoint, and allow for users to build these out with custom properties. This may be important in the far future where we want exception parameters to be machine-readable and potentially parsed by an LLM.
Metadata
Metadata
Assignees
Labels
ready_for_releaseIssue has been completed, but the resolution has not been pushed out to a release.Issue has been completed, but the resolution has not been pushed out to a release.