Skip to content

Releases: cockroachdb/errors

Dependency updates

25 Jun 13:20
@knz knz
fc43a0e
Compare
Choose a tag to compare

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

13 Apr 16:54
@knz knz
72ec752
Compare
Choose a tag to compare

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

18 Mar 20:45
Compare
Choose a tag to compare

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

11 Nov 16:29
@knz knz
90d1628
Compare
Choose a tag to compare

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`

29 Oct 20:00
@knz knz
b41978a
Compare
Choose a tag to compare

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)

21 Aug 10:52
@knz knz
Compare
Choose a tag to compare

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 a redact.SafeValue, instead of an errors.SafeMessager as before.

Major changes

  • A new interface errors.SafeFormatter is introduced, and should be preferred to errors.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 by errors.New*() and errors.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)

13 Aug 14:11
@knz knz
Compare
Choose a tag to compare

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)

v1.5.0

15 Jun 14:13
Compare
Choose a tag to compare
Update go.mod.