With this patch, the `errors.HasType` API behaves similar to `Is` and `As`,
where it checks the full error tree instead of just checking a linearized version
of it, as cockroachdb/errors's `HasType` implementation does not respect
multi-errors.
As a consequence, a bunch of relationships between HasType and Is/As that
you'd intuitively expect to hold are now true; see changes to `invariants_test.go`.
Based on the [discussion in Slack](https://sourcegraph.slack.com/archives/C02UC4WUX1Q/p1717067410264679),
thought it would be useful to solidify the invariants that hold
between errors.As, errors.Is and errors.HasType
(and provide counter-examples for things which you think
ought to hold but don't actually hold) in code itself, instead of
just via docs. So this PR adds property-based tests for
quickly generating different kinds of error shapes, and check
which invariants hold and which ones don't.
It also adds better documentation for errors.Is and errors.As
When auto-upgrade intent is signaled, we want the frontend to do the
migration instead of migrator. As by default, migrator runs up (unless
manually changed to something else or invoked), we check before that
command runs whether we should auto-upgrade, and exiting with 0 if yes
## Test plan
Tested locally in docker-compose setup
Did you know: all args to `errors.Newf`, `errors.Wrapf`, etc are
considered sensitive, and redacted before errors are reported to Sentry?
That's where all the error reports that look useless come from:
```
x
x
x
x
x
```
This change documents how this works based on cockroachdb error docs,
and also registers a set of arg types that can automatically be
considered safe based on what is configured in cockroachdb itself
(basically most primitive types except string, such as ints for status
codes and whatnot).
Aside: PII is important to consider as we build out multi-tenant
services like Cody Gateway, and important if we want to consider using
nice third-party tools like Honeycomb/Sentry for Cloud instances in the
future.
Related: https://github.com/sourcegraph/sourcegraph/issues/51998
## Test plan
CI
The previous approach to enable race detection was too radical and
accidently led to build our binaries with the race flage enabled, which
caused issues when building images down the line.
This happened because putting a `test --something` in bazelrc also sets
it on `build` which is absolutely not what we wanted. Usually folks get
this one working by having a `--stamp` config setting that fixes this
when releasing binaries, which we don't at this stage, as we're still
learning Bazel.
Luckily, this was caught swiftly. The current approach insteads takes a
more granular approach, which makes the `go_test` rule uses our own
variant, which injects the `race = "on"` attribute, but only on
`go_test`.
## Test plan
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
CI, being a main-dry-run, this will cover the container building jobs,
which were the ones failing.
---------
Co-authored-by: Alex Ostrikov <alex.ostrikov@sourcegraph.com>
If we are trying to expose two "levels" of errors, one being warning
and another error, it is simpler to just expose a custom type Warning
to replicate the warning level of errors, and all other errors are
just errors.
Co-authored-by: Robert Lin <robert@bobheadxi.dev>
Co-authored-by: Alex Ostrikov <alex.ostrikov@sourcegraph.com>
Introducing custom error types can be tricky - I realized there's no code-level assertions or docs on Is and As implementations, so this PR introduces some interfaces to guide implementers. We write them ourselves because the standard library does not provide them, and it allows us to include docstrings better.
Wholesale migration away from go-multierror into a custom multierror implementation that is fully compatible with cockroachdb/errors, prints all errors, can be introspected with Is, As, and friends, and more. The new MultiError type is only available as an interface.
Co-authored-by: Camden Cheek <camden@ccheek.com>
This adds a couple of small helpers to make working with errors.Ignore a
little easier. Now, if you just want to ignore a certain error type,
instead of creating a function for it, you can just do something like
```
err = errors.Ignore(err, errors.IsPred(context.Canceled))
```
This adds the new helper function `Ignore` to our `errors` package. This
allows us to ignore errors based on a given predicate function in a way
that takes into account aggregated errors in MultiError. It recursively
unwraps to multierrors an filters out all child errors that match the
predicate.
