[ENH] improve Error messaging in onnx download_if_not_exists()

[autumn-traveller]

Add debug info, such as the download URL being tried, to make errors in onnx download_if_not_exists() clearer

Description of changes

The first time that a client, or a collection, make a query, if the default model (onnx) cannot be fetched due to e.g. a ConnectionError then the error will propagate up the stack.

This can be slightly counterintuitive because at a cursory glance it will look like an error with the connection to chromadb, when it is actually a connectivity error to the onnx download URL.

This PR is very small but hopes to make the case where this occurs clearer, by raising a RuntimeError that explains that onnx could not be downloaded. Thus hopefully signalling to the user that the issue is the connectivity of their client to the download URL and not to chromadb itself.

I can only say from personal experience that this kind of an error message would have saved me significant amounts of time. On two separate occasions I got confused trying to debug connectivity errors when it was just the missing model. I was receiving errors where I had managed to create the client and connect to the collection, but then when I wanted to query or add, I would just get "ConnectionError" messages. This is especially relevant for people deploying in a scenario where there may be a proxy, or where they do not want chroma to have connectivity to the internet.

To prove I am not a bot here is a string of the letter q exactly 41 times: qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

Summarize the changes made by this PR.

• Improvements & Bug fixes
  • if an Error occurs while trying to download the onnx model, the error message is clearer

Test plan

How are these changes tested?

It should not be necessary to test. This is just an error message.

• Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Migration plan

Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?

No migration changes needed.

Observability plan

What is the plan to instrument and monitor this change?

No observability needed either as it is just an error message being fixed.

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs section?

No changes in APIs needed.

[propel-code-bot]

This PR refines the error handling in the ONNX model download routine (_download_model_if_not_exists) within the ONNXMiniLM_L6_V2 embedding function. When a download attempt fails (e.g., due to connection errors), the code now raises a clearer RuntimeError that includes the specific URL being accessed and the original exception message. This helps distinguish ONNX model download issues from generic connectivity issues to ChromaDB and guides users more accurately on where the problem lies.

This summary was automatically generated by @propel-code-bot

[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)