feat: Api response extensions

[benjaminVadon]

No description provided.

[Copilot]

Pull request overview

Adds Kotlin extension helpers to streamline handling of ApiResponse success/error cases (callbacks + mapping), and extends the core ApiResponse model with an isError() convenience method.

Changes:

• Introduces ApiResponse extensions: onSuccess, onError, on, mapSuccess, mapError, map with Sentry reporting on invalid states.
• Adds ApiResponseException / ApiErrorException used for reporting inconsistent API payloads.
• Adds isError() to ApiResponse model.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File	Description
Network/src/main/kotlin/com/infomaniak/core/network/utils/apiResponse/ApiResponseExt.kt	New ApiResponse extension API for success/error callbacks and mapping with Sentry capture.
Network/src/main/kotlin/com/infomaniak/core/network/utils/apiResponse/ApiResponseException.kt	New exception for “success but data is null” cases.
Network/src/main/kotlin/com/infomaniak/core/network/utils/apiResponse/ApiErrorException.kt	New exception for “error but error payload is null” cases.
Network/Models/src/main/java/com/infomaniak/core/network/models/ApiResponse.kt	Adds isError() helper to support new extensions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Failed to generate code suggestions for PR

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 Security concerns Sensitive information exposure: The new toString() override in ApiResponse prints data, uri, and error fields. The new ApiResponseException and ApiErrorException classes include the full response string in their messages, and the onSuccess/onError extensions capture these exceptions with Sentry. If API responses contain sensitive data (e.g., tokens, user details), this information may be transmitted to Sentry and appear in logs. Consider sanitizing exception details or avoiding printing sensitive fields in toString().

⚡ Recommended focus areas for review False-positive Sentry reports The onSuccess extension reports an ApiResponseException to Sentry whenever data is null on a successful response, but ApiResponse declares data as T?. If an endpoint uses a nullable type (e.g., String?) or returns no data (e.g., Unit), a legitimate success response with null data will incorrectly trigger a Sentry report. inline fun <T> ApiResponse<T>.onSuccess(block: T.() -> Unit): ApiResponse<T> = apply { if (isSuccess()) { data?.run(block) ?: Sentry.captureException(ApiResponseException(this)) } } Sensitive data exposure The new toString() override includes data, uri, and error fields. The new exception classes embed the full response in their messages, and the onSuccess/onError extensions send these exceptions to Sentry. If an API response contains sensitive information such as authentication tokens or personal data, it may be transmitted to Sentry. The actual risk depends on the contents of production API responses. override fun toString(): String { return "ApiResponse(result=$result, data=$data, uri=$uri, error=$error, responseAt=$responseAt )" }

[github-actions]

PR Code Suggestions ✨

No code suggestions found for the PR.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[LouisCAD]

The name ApiErrorException doesn't really reflect what it's always about (according to the exception message). Same for ApiResponseException.
Nothing in the class name tells you that it's about missing data.

I have multiple suggestions:

1. Merge these 2 exceptions into one, with the name of any of them, and error message as a constructor parameter
2. Create a sealed class hierarchy with the name ApiResponseException for the base class, and 2 nested subclasses named something like MissingErrorField and MissingDataField.

[LouisCAD]

Will we really need this function?

I feel like its usages would not look idiomatic, and a bit redundant with repetition of the word on:

someResponse.on(
    onSuccess = { whatever() },
    onFailure = { somethingElse() }

I think onSuccess and onError are good enough for our use cases.