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

[ABW-3259] NPS survey upload using body params #1200

Merged
merged 3 commits into from
Jul 5, 2024

Conversation

danvleju-rdx
Copy link
Contributor

@danvleju-rdx danvleju-rdx commented Jul 5, 2024

Jira ticket: ABW-3259

Description

This PR changes the NPS survey upload from using query parameters to body parameters. Refiner requires this to ensure the NPS score is treated as a number instead of a string.


do {
_ = try await httpClient.executeRequest(urlRequest)
_ = try await httpClient.executeRequest(urlRequest) { statusCode in
[200, 202].contains(statusCode)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This request returns a 202 response code. For other requests, we want to be more restrictive and accept only a 200 response code.

Copy link
Contributor

@matiasbzurovski matiasbzurovski left a comment

Choose a reason for hiding this comment

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

Looking good, some small suggestions only.

(Assume test worked fine on NPS dashboard, to which I don't have access)

let (data, urlResponse) = try await session.data(for: request)

guard let httpURLResponse = urlResponse as? HTTPURLResponse else {
throw ExpectedHTTPURLResponse()
}

guard httpURLResponse.statusCode == BadHTTPResponseCode.expected else {
let isSuccessStatusCode = isStatusCodeValid?(httpURLResponse.statusCode) ?? (httpURLResponse.statusCode == BadHTTPResponseCode.expected)
Copy link
Contributor

Choose a reason for hiding this comment

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

not part of this PR, but wondering why are we checking the success code from something like BadHTTPResponseCode 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question :)
@GhenadieVP do you think we can move the expected success code elsewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would say we can completely remove expected and butExpected from BadHTTPResponseCode

@@ -5,5 +5,5 @@ public struct HTTPClient: Sendable, DependencyKey {

// MARK: HTTPClient.ExecuteRequest
extension HTTPClient {
public typealias ExecuteRequest = @Sendable (URLRequest) async throws -> Data
public typealias ExecuteRequest = @Sendable (_ request: URLRequest, _ isStatusCodeValid: ((Int) -> Bool)?) async throws -> Data
Copy link
Contributor

Choose a reason for hiding this comment

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

instead of a closure to determine whether a status code is considered valid, I would have it receive an array of accepted status codes. We could use just Int or define an enum with the predefined values (example).

Copy link
Contributor

Choose a reason for hiding this comment

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

Either what @matiasbzurovski suggested, or return the status code along with the Data and let the consumer decide if it is valid or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@matiasbzurovski not sure if we need such an ample enum, but an array of Int sounds good

Copy link
Contributor

Choose a reason for hiding this comment

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

we may not want to add all the cases (since we are not mapping the int value to the corresponding case anyway), but if define at least the expected ones (200 & 202 for now) we could refer it directly (HttpStatusCode.ok vs BadHTTPResponseCode.expected)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agree

@@ -70,7 +70,7 @@ extension GatewayAPIClient {
urlRequest.timeoutInterval = timeoutInterval
}

let data = try await httpClient.executeRequest(urlRequest)
let data = try await httpClient.executeRequest(urlRequest, nil)
Copy link
Contributor

Choose a reason for hiding this comment

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

We can define a helper method to avoid sending nil most of the times

extension HTTPClient {
	func executeRequest(_ request: URLRequest) async throws -> Data {
		try await executeRequest(request, nil)
	}
}

or if you follow my previous comment:

extension HTTPClient {
	func executeRequest(_ request: URLRequest) async throws -> Data {
		try await executeRequest(request, [.ok])
	}
}

@@ -33,3 +31,18 @@ public struct ResponseDecodingError: Swift.Error {
self.error = error
}
}

// MARK: - HTTPStatusCode
public enum HTTPStatusCode: Int, Error {
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@danvleju-rdx danvleju-rdx merged commit d2194db into main Jul 5, 2024
6 checks passed
@danvleju-rdx danvleju-rdx deleted the ABW-3259-nps-survey-upload-using-body branch July 5, 2024 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants