Lots of code in the VA package handles probs, often returning them when something has gone wrong. On the one hand, this makes sense: the ACME spec defines several problems that have to do with validation, and we want to ensure that we can properly store and return problems of the appropriate types when the client checks their authz state.
However, we also return lots of probs.ServerInternal when something has gone wrong in our own infrastructure, like a failed gRPC connection. This is bad, because it makes it very hard to tell the difference between problems that merely need to be stored and problems that are much worse.
As an example, see va.doRemoteOperation. It returns an MPIC summary and a problem, and often both are non-nil. Sometimes that problem is "some RVAs didn't see the right token", which is a simple validation failure. Sometimes that problem is "the result the RVA returned was malformed" or "we couldn't reach an RVA", which are also validation failures, but they're our fault, not the applicant's. And sometimes that problem is "we aren't even configured with enough RVAs to attempt MPIC", in which case the summary is nil.
We should ensure that all issues within our own infrastructure are returned as errors, and all mere validation issues are returned as problems. We can convert our own issues into problems at the boundary of the VA, for storage in the SA.
Lots of code in the VA package handles
probs, often returning them when something has gone wrong. On the one hand, this makes sense: the ACME spec defines several problems that have to do with validation, and we want to ensure that we can properly store and return problems of the appropriate types when the client checks their authz state.However, we also return lots of
probs.ServerInternalwhen something has gone wrong in our own infrastructure, like a failed gRPC connection. This is bad, because it makes it very hard to tell the difference between problems that merely need to be stored and problems that are much worse.As an example, see
va.doRemoteOperation. It returns an MPIC summary and a problem, and often both are non-nil. Sometimes that problem is "some RVAs didn't see the right token", which is a simple validation failure. Sometimes that problem is "the result the RVA returned was malformed" or "we couldn't reach an RVA", which are also validation failures, but they're our fault, not the applicant's. And sometimes that problem is "we aren't even configured with enough RVAs to attempt MPIC", in which case the summary is nil.We should ensure that all issues within our own infrastructure are returned as errors, and all mere validation issues are returned as problems. We can convert our own issues into problems at the boundary of the VA, for storage in the SA.