-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error handling audit #81
Comments
fixes #81 Xtask was running npm install instead of npm clean-install, while the cache was looking at the package-lock.json checksum.This means linux and osx builds never would hit the cache, and upload to wrong keys.
putting that in the api-1.0 effort, although I think it's mostly done? |
Not sure if it belongs in here, but error handling in native plugins is pretty cumbersome as well. Is there an issue tracking this specifically? |
@o0Ignition0o I don't think there is an issue for that (at least not that I'm aware of) |
#1487 make some error enums private, but the remaining ones are still in need of an audit. I think some variants are not used anymore. And the enums should probably be made |
In the spirit of #1142 (comment), we generally want to use a
|
Let’s… not. |
If we wish to improve the quality of our generated error documentation:
We could use this mechanism to, for instance, number all of our errors: e.g.: |
#1621 completes the audit of error-handling-related Rust APIs for 1.0. Removing the label and milestone, but leaving this issue open as in 1.x we’ll want to audit the presentation / formatting of errors in GraphQL responses and in logs, as well as maybe add error codes. |
Create a comprehensive list of all errors.
Ensure that error messages have:
Sensitive information must not be leaked.
Consider metrics for infrastructure errors.
The text was updated successfully, but these errors were encountered: