Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove entropy from client failures #262

Merged
merged 3 commits into from
Feb 21, 2025
Merged

Remove entropy from client failures #262

merged 3 commits into from
Feb 21, 2025

Conversation

oguzhanunlu
Copy link
Member

@oguzhanunlu oguzhanunlu commented Feb 20, 2025

This PR removes details from client failures and include status code only so that entropy is minimized.

ref: PDP-1642

@oguzhanunlu oguzhanunlu self-assigned this Feb 20, 2025
@oguzhanunlu oguzhanunlu changed the title Remove entropy for client failures from http4s registry Remove entropy from client failures Feb 20, 2025
@oguzhanunlu oguzhanunlu marked this pull request as ready for review February 20, 2025 15:39
val error = s"Unexpected server response: $body"
RegistryError.ClientFailure(error).asLeft
}
val error = s"Unexpected server response: ${response.status.code}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "Unexpected response code" is a better message?

Copy link
Member Author

@oguzhanunlu oguzhanunlu Feb 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found the collector bug I'm referring to: snowplow/stream-collector#210

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean, passing tests would trick us if/when toString changes, updating

Copy link
Contributor

@istreeter istreeter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice :)

@oguzhanunlu oguzhanunlu merged commit 7c2434c into develop Feb 21, 2025
1 check passed
@oguzhanunlu oguzhanunlu deleted the remove-entropy branch February 21, 2025 07:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants