[ENH]: Improved error reporting

[AlabasterAxe]

Description of changes

This PR reworks the way error handling works with the JavaScript client. Previously, the api would return objects with error messages under certain circumstances and throw errors in other circumstances. This standardizes that by supplying a custom fetch implementation that translates the http error codes and the server error responses, into a standardized set of errors that are thrown by the client functions.

Test plan

• Updated javascript tests
• wrote a new test

Documentation Changes

• This is a breaking change to the API of the client so this should be documented.

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[nicolasgere]

I think fetch will not raise if status is 500 no?

[AlabasterAxe]

Yeah, that's a good call. I think we may need to have a larger conversation about what we want our policy to be for these things (although I guess that's my task :) ). Ideally, we'd have a standardized error API at the client level.

e.g.

ChromaConnectionError
ChromaServerError
ChromaUnknownError

[tazarov]

This is super nice!

A frequent problem I see is JS sucks with dual-stack systems where most people will connect to localhost, which maps to :1; however, their server is listening on 127.0.0.1. Can we force JS to try both stacks before giving up?

[AlabasterAxe]

That is an interesting question. My gut reaction is that it might cause some surprising behaviors in certain circumstances (e.g. the user has something else running at :1:8000 which causes some cryptic errors).

I think that would be a good conversation to have but I think adding that functionality would be outside of the original scope of this PR.

[tazarov]

@AlabasterAxe, the backend sometimes returns error + message, sometimes just error. Could that break some of the code below?

[AlabasterAxe]

when you say error + message, is that on the response body?

or are you referring to the message field on the error object? that can get thrown by the call to fetch?