Releases: cockroachdb/errors
Dependency updates
This is a maintenance release which upgrades the library's dependencies.
(With the exception of sentry-go
, which is tracked separately in issue #41)
The most visible change is the upgrade to redact
v1.1 which introduces automatic formatting of structs and arrays that mix safe and unsafe values for reporting. It also extends the errors.SafePrinter
interface with new methods to format numbers.
v1.8.4: go 1.16 compatibility & gogoproto 1.3
This release is needed for correctness when using the errors library to communicate errors between two processes, one built with a post-go1.16 runtime and one with a pre-go1.16 runtime.
v1.8.3
This release adds support for automatic en/decoding of gRPC Status
-based errors in EncodeError()
and DecodeError()
, enabled by importing the extgrpc
package. It also fixes the "skippy peanut butter" gogoproto vulnerability in all generated Protobuf structs, and recompiles Protobufs in the extgrpc
, exthttp
, and grpc
packages using gogoproto 1.2 rather than 1.3.
v1.8.1: preserve compatibility with gogoproto v1.2
Version v1.8.0 was forcing an upgrade to gogoproto v1.3.
This was not strictly required, and was creating an incompatibility with CockroachDB.
This release drops this forced dependency requirement to the same version as required in previous releases.
v1.8.0: new module `oserror`
This version of the library includes working replacements for error predicates in os
, via a new sub-package oserror
.
These new functions oserror.IsTimeout()
, oserror.IsExist()
, oserror.IsNotExist()
and oserror.IsPermission()
can recognize the same errors as their analog in package os
, with the following improvements:
- they are able to peek through layers of error wrappers, which the functions in
os
cannot; - they are able to recognize errors across the network, through
Encode
/Decode
cycles.
Note that the new functions will not be able to identify os errors encoded using a previous version of the library, unless they were encoded on exactly the same OS / platform combination (identified by GOARCH/GOOS). Therefore, care should be taken to ensure all components in a distributed system are upgraded to the newer version before the predicates can be used safely for errors transported over the network.
v1.7.0: New error redaction logic, and more! (API CHANGE)
The main change in this release is a radical change in how the library internally learns about and treats strings to separate "safe" and "unsafe" information.
Despite the major version bump, only very few APIs have been changed in a backward-incompatible way.
Also, no new strings are considered safe for reporting that were not already before, unlike what happened in v1.6.0.
(For context, "safe" means known not to contain PII, confidential data etc, and thus safe to report to Sentry and other telemetry.)
Highlights
- More complete error messages in Sentry reports,
- More details of errors are preserved when they are embedded inside other errors.
- Several bug fixes in error formatting.
- A more complete test suite to test error formatting and sentry reports.
Backward-incompatible changes
- The
errors.Safe()
function now returns aredact.SafeValue
, instead of anerrors.SafeMessager
as before.
Major changes
-
A new interface
errors.SafeFormatter
is introduced, and should be preferred toerrors.Formatter
in the general case. -
Prior to this release, the only safe strings were error types and the explicit "Safe Details" payloads as implemented by the
SafeDetailer
interface,errors.WithSafeDetails()
and the implicit capture of detail strings byerrors.New*()
anderrors.Wrap*()
constructors.This machinery has been complemented by the new package https://github.com/cockroachdb/redact (previously introduced in CockroachDB) which is now used throughout the library for error redaction.
The
SafeDetailer
interface and corresponding safe strings are still supported (and reported in Sentry if found). Backward-compatible safe detail strings are also generated by the new redact-based code for the benefit of networked code using mixed library versions.
v1.6.0: make New() and Wrap() consider their string as PII-free (BREAKING CHANGE)
THIS IS A POSSIBLY BREAKING CHANGE. READ CAREFULLY
The errors.New()
, errors.NewWithDepth()
, errors.Wrap()
and
errors.WrapWithDepth()
now consider that their string argument do
not contain PII or unsafe data, and the string is now also included
in Sentry reports.
This is a breaking change if your code uses the included
Sentry reporting: in previous versions, only the format
argument to errors.Newf
, errors.Wrapf
etc. was considered to be
PII-free and reportable. With the new version, more strings
are considered PII-free and reportable.
This also means that care must be taken when using this errors
library as drop-in replacement for other errors libraries: callers
that use New()
and Wrap()
directly must be audited to ensure that
they indeed pass strings that are safe for reporting to Sentry.
This can be enforced e.g. via linters that assert that the argument is
a literal (constant) string. This is the approach taken e.g. in
CockroachDB.
The motivation for this is discussed here: cockroachdb/cockroach#49752
and cockroachdb/cockroach#49660 (comment)