Remove entropy from client failures #262
Conversation
oguzhanunlu
force-pushed
the
remove-entropy
branch
from
d102c1f to
6ce796f
Compare
oguzhanunlu
changed the title
oguzhanunlu
force-pushed
the
remove-entropy
branch
from
6ce796f to
b7a39d5
Compare
| val error = s"Unexpected server response: $body" | ||
| RegistryError.ClientFailure(error).asLeft | ||
| } | ||
| val error = s"Unexpected server response: ${response.status.code}" |
There was a problem hiding this comment.
Maybe "Unexpected response code" is a better message?
There was a problem hiding this comment.
definitely, not every response is related to server
| } | ||
|
|
||
| Http4sRegistryLookup(client).lookup(repositoryRef, schemaKey).map { result => | ||
| result should beLeft(ClientFailure(s"Unexpected server response: ${Forbidden.code}")) |
There was a problem hiding this comment.
I think you should assert that the string matches the exact string you expect, i.e. check for
"Unexpected server response: 403"
In my experience, in tests it is unhelpful to be too clever with using stringified objects.
Imagine http4s makes a code change in a future release, where they change the toString method on Forbidden:
object Forbidden extends Status {
override def toString(): String = "foo"
}Would your unit test pass or fail if http4s made that change?
I know that sounds like a silly example, but I can remember bugs/incidents caused by exactly this mistake! There was a bug in the old collector, where akka changed how they serialize sensitive headers. We didn't notice that akka had changed their implementation, because our unit tests made the same mistake as the code under test.
There was a problem hiding this comment.
Found the collector bug I'm referring to: snowplow/stream-collector#210
There was a problem hiding this comment.
I see what you mean, passing tests would trick us if/when toString changes, updating
This PR removes details from client failures and include status code only so that entropy is minimized.
ref: PDP-1642