Mitar

Oh, sorry. I misread. Ignore my comment.

And update on this?

So the error was `ErrTemporarilyUnavailable` returned from `storeErrorsToRevocationError`.

The spec is slightly confusing: [Here](https://datatracker.ietf.org/doc/html/rfc7009#section-2.2.1) it references [Section 5.2 of [RFC6749]](https://datatracker.ietf.org/doc/html/rfc6749#section-5.2) but also later on says "If the server responds with HTTP status code 503" so at least 503...

No? The `errors.WithStack` includes wrapper stack traces, it adds a stack trace every time, you just have to traverse the chain up and retrieve all of them. If you look...

OK, here is an example Go program: ```golang package main import ( "encoding/json" "fmt" "github.com/ory/x/errorsx" "github.com/pkg/errors" "github.com/sirupsen/logrus" ) func a() (error, error) { err1, err2 := b() if err1 !=...

See [this example](https://github.com/ory/hydra/blob/master/persistence/sql/persister.go#L28-L29) where `errorsx.WithStack` backfires. You call `errors.New` which creates an error with a stack trace. And then when you call `errorsx.WithStack(ErrNoTransactionOpen)` later on, the stack trace is not...

I think it might be reasonable to introduce something like `x.Serror` which would be an error with a stack trace and we should set which functions are returning then `x.Serror`...

@zepatrik I think this proves my point. Which is, making `hash.ErrUnknownHashAlgorithm` using `errors.New` is the source of problems. You do not want that value to have stack trace at all....

OK, I made the package. Check it out: https://gitlab.com/tozd/go/errors I think it is perfect reimplementation of the `github.com/pkg/errors` for modern Go. Feedback welcome. I think it addresses the issue described...