app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt (1)

58-66: Please add route coverage for the new includeContent branches.

This change adds a new 400 path, changes the /messages response shape, and makes /messages/{id} depend on the same content mapper, but there are no tests covering omitted/true/invalid includeContent values or text/data payload mapping.

Also applies to: 119-121, 300-300, 321-364

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt`
around lines 58 - 66, Add tests to cover the new includeContent query handling
and response mapping: exercise the MessagesRoutes handlers that serve the
/messages list and /messages/{id} endpoints (locate the route code around the
includeContent parsing block and the content-mapper function used for both list
and single-item responses). Specifically add cases for includeContent=false
(default) to assert text/data payloads are omitted and response shape unchanged,
includeContent=true to assert the mapper returns text/data fields correctly, and
an invalid value (e.g., includeContent=notabool) to assert a 400 with message
"includeContent must be true or false". Also update existing message-list and
message-by-id test expectations to use the same content-mapper assertions so
both endpoints are covered under omitted/true/invalid branches.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt (1)

332-348: ⚠️ Potential issue | 🟠 Major

Wrap content deserialization in try-catch to prevent one malformed record from failing the entire response.

The message.textContent and message.dataContent properties internally call gson.fromJson(), which can throw JsonSyntaxException if the stored content JSON is malformed. Since these are optional fields, a parse failure for one message should not abort the entire GET /messages response.

🛡️ Proposed fix with error isolation

-            textMessage = when (includeContent) {
-                true -> message.textContent?.let {
-                    TextMessage(it.text)
-                }
-
-                else -> null
-            },
-            dataMessage = when (includeContent) {
-                true -> message.dataContent?.let {
-                    me.capcom.smsgateway.modules.localserver.domain.DataMessage(
-                        data = it.data,
-                        port = it.port.toInt()
-                    )
-                }
-
-                else -> null
-            },
+            textMessage = if (includeContent) {
+                try {
+                    message.textContent?.let { TextMessage(it.text) }
+                } catch (e: Exception) {
+                    null
+                }
+            } else null,
+            dataMessage = if (includeContent) {
+                try {
+                    message.dataContent?.let {
+                        me.capcom.smsgateway.modules.localserver.domain.DataMessage(
+                            data = it.data,
+                            port = it.port.toInt()
+                        )
+                    }
+                } catch (e: Exception) {
+                    null
+                }
+            } else null,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt`
around lines 332 - 348, The deserialization of message.textContent and
message.dataContent can throw JsonSyntaxException and must be isolated so one
bad record doesn't fail the whole GET /messages response; wrap each access to
message.textContent and message.dataContent in a try-catch that catches
JsonSyntaxException (or Exception) and on parse error log the failure and return
null for that field so TextMessage(...) or DataMessage(...) is only constructed
on successful parse; update the mapping in MessagesRoutes.kt where
includeContent is handled (the when branches constructing TextMessage and
me.capcom.smsgateway.modules.localserver.domain.DataMessage) to perform the
safe-parse logic instead.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt (1)

326-342: ⚠️ Potential issue | 🟠 Major

Wrap content parsing to prevent single malformed message from failing entire response.

When includeContent=true, message.textContent and message.dataContent call gson.fromJson() internally. If any message has corrupted/malformed JSON content, the exception will propagate and fail the entire GET /messages response. Since these fields are optional, isolate parsing failures per item.

🛡️ Proposed fix

-            textMessage = when (includeContent) {
-                true -> message.textContent?.let {
-                    TextMessage(it.text)
-                }
-
-                else -> null
-            },
-            dataMessage = when (includeContent) {
-                true -> message.dataContent?.let {
-                    DataMessage(
-                        data = it.data,
-                        port = it.port.toInt()
-                    )
-                }
-
-                else -> null
-            },
+            textMessage = if (includeContent) {
+                runCatching { message.textContent }
+                    .getOrNull()
+                    ?.let { TextMessage(it.text) }
+            } else null,
+            dataMessage = if (includeContent) {
+                runCatching { message.dataContent }
+                    .getOrNull()
+                    ?.let { DataMessage(data = it.data, port = it.port.toInt()) }
+            } else null,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt`
around lines 326 - 342, In MessagesRoutes.kt, when includeContent is true you
must guard the per-message parsing of message.textContent and
message.dataContent (which call gson.fromJson) so a single malformed JSON
doesn't fail the whole GET /messages response; wrap the parsing logic used to
create TextMessage(...) and DataMessage(...) in try/catch blocks, catch JSON
parsing exceptions from gson.fromJson, log the error with message
identifier/context, and return null for textMessage or dataMessage on failure so
the rest of the items still return; update the branches that set textMessage and
dataMessage to use these safe-parsing wrappers.

app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt (1)

89-93: ⚠️ Potential issue | 🔴 Critical

Gson lacks native UShort support — deserialization of MessageContent.Data.port will fail.

The dataContent getter at line 91 calls gson.fromJson(content, MessageContent.Data::class.java), but MessageContent.Data has a port: UShort field. The plain Gson() instance at line 100 has no custom TypeAdapter for UShort, so deserialization will fail at runtime.

Register a UShort type adapter:

🛠️ Proposed fix

-        private val gson = Gson()
+        private val gson = GsonBuilder()
+            .registerTypeAdapter(UShort::class.java, object : JsonDeserializer<UShort>, JsonSerializer<UShort> {
+                override fun deserialize(json: JsonElement, typeOfT: Type, context: JsonDeserializationContext): UShort {
+                    return json.asInt.toUShort()
+                }
+                override fun serialize(src: UShort, typeOfSrc: Type, context: JsonSerializationContext): JsonElement {
+                    return JsonPrimitive(src.toInt())
+                }
+            })
+            .create()

Add these imports:

import com.google.gson.GsonBuilder
import com.google.gson.JsonDeserializer
import com.google.gson.JsonSerializer
import com.google.gson.JsonDeserializationContext
import com.google.gson.JsonSerializationContext
import com.google.gson.JsonElement
import com.google.gson.JsonPrimitive
import java.lang.reflect.Type

Also applies to: 100-100

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt` around lines
89 - 93, The dataContent getter uses gson.fromJson to parse MessageContent.Data
which contains a port: UShort, but the gson instance (gson) has no UShort
TypeAdapter so deserialization will fail; register a Gson
TypeAdapter/serializer/deserializer for kotlin.UShort on the gson used (the gson
property/instance) so UShort values are converted to/from JSON (e.g., serialize
as number/string and deserialize back to UShort), then rebuild the gson used by
the dataContent getter to use that adapter (update the gson construction where
the gson instance is created).

app/src/main/assets/api/swagger.json (1)

349-422: Clarify hashedMessage inclusion behavior.

The descriptions for textMessage and dataMessage state they're present "only when includeContent=true", but hashedMessage description says "if isHashed is true" without mentioning includeContent. Is hashedMessage always returned when isHashed=true, regardless of includeContent? If so, document this explicitly. If not, align the description with the other fields.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/assets/api/swagger.json` around lines 349 - 422, The swagger
schema is ambiguous about when smsgateway.HashedMessage is returned: update the
description for the hashedMessage property to explicitly state whether it is
gated by includeContent or returned whenever isHashed=true to match
textMessage/dataMessage behavior; specifically edit the hashedMessage
description to either "Present only when `includeContent=true` and
`isHashed=true`" or "Returned when `isHashed=true` regardless of
`includeContent`" (choose the correct behavior), ensuring consistency with the
textMessage and dataMessage descriptions and referencing the hashedMessage,
textMessage, dataMessage, includeContent and isHashed symbols so reviewers can
locate the change.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt (1)

89-92: ⚠️ Potential issue | 🔴 Critical

MessageContent.Data.port deserialization is unsafe with plain Gson.

dataContent (Line 89-Line 92) uses the gson instance from Line 100 (Gson()), but MessageContent.Data.port is UShort. This can fail at runtime when reading Data messages.

#!/bin/bash
# Verify whether UShort Gson adapters exist and how gson is initialized for Message deserialization.

rg -n "UShort|TypeAdapter|registerTypeAdapter|GsonBuilder\\(|Gson\\(" --type=kt -C2
sed -n '80,110p' app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt

Also applies to: 100-100

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt` around lines
89 - 92, The current dataContent getter uses the plain gson instance (Gson())
which cannot safely deserialize MessageContent.Data.port of type UShort; create
and use a GsonBuilder-backed gson that registers a custom
TypeAdapter/JsonSerializer/JsonDeserializer for kotlin.UShort (or its boxed
class) that converts numeric JSON values into UShort and handles nulls/invalid
values, replace the simple Gson() assignment with this GsonBuilder
configuration, and ensure the Message.dataContent getter continues to use that
gson so MessageContent.Data.port is deserialized safely.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt (1)

89-91: ⚠️ Potential issue | 🔴 Critical

Don’t rely on plain Gson() to round-trip Kotlin UShort.

MessageContent.Data.port is a Kotlin UShort, while Gson’s current docs describe built-in special handling around Java primitives/common types and exact-type custom adapters when you need something else. This means this new dataContent path should be verified rather than assumed; if it is not adapter-backed here, the first data-message read can fail while building the new response payloads. (google.github.io)

#!/bin/bash
set -euo pipefail

echo "MessageContent.Data definition:"
sed -n '1,40p' app/src/main/java/me/capcom/smsgateway/domain/MessageContent.kt

echo
echo "Message entity JSON accessors:"
sed -n '80,110p' app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt

echo
echo "Search for any UShort Gson adapter or configured GsonBuilder usage:"
rg -nP --type=kt 'UShortTypeAdapter|registerTypeAdapter|GsonBuilder\(|TypeAdapter<\s*UShort'

Expected: MessageContent.Data.port is UShort, this file still uses private val gson = Gson(), and this path is not obviously wired through a UShort adapter. If that is what you see, switch this accessor path to the app’s configured GsonBuilder or register an explicit adapter here.

Also applies to: 95-100

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt` around lines
89 - 91, The dataContent getter uses a plain Gson instance (private val gson =
Gson()) to deserialize MessageContent.Data which has a UShort field
(MessageContent.Data.port); replace this with the app's configured Gson (the
shared GsonBuilder instance) or create/register a UShort TypeAdapter and use
that Gson for the dataContent getter (also update the similar accessor around
lines 95-100) so UShort round-tripping is handled correctly rather than relying
on the default Gson().

app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt (1)

326-342: ⚠️ Potential issue | 🟠 Major

Don’t let one bad payload abort the whole response.

message.textContent / message.dataContent can throw here, and this helper is used by the paged list plus the always-include GET /messages/{id} path. Because these fields are optional, degrade just that row to null instead of turning the entire response into a 500.

💡 Minimal guard

-            textMessage = when (includeContent) {
-                true -> message.textContent?.let {
-                    TextMessage(it.text)
-                }
-
-                else -> null
-            },
-            dataMessage = when (includeContent) {
-                true -> message.dataContent?.let {
-                    DataMessage(
-                        data = it.data,
-                        port = it.port.toInt()
-                    )
-                }
-
-                else -> null
-            },
+            textMessage = if (includeContent) {
+                try {
+                    message.textContent?.let { TextMessage(it.text) }
+                } catch (_: RuntimeException) {
+                    null
+                }
+            } else {
+                null
+            },
+            dataMessage = if (includeContent) {
+                try {
+                    message.dataContent?.let {
+                        DataMessage(
+                            data = it.data,
+                            port = it.port.toInt()
+                        )
+                    }
+                } catch (_: RuntimeException) {
+                    null
+                }
+            } else {
+                null
+            },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt`
around lines 326 - 342, In MessagesRoutes.kt where the response row builds
textMessage and dataMessage (the when(includeContent) blocks that create
TextMessage and DataMessage from message.textContent and message.dataContent),
guard the optional payload access so a thrown exception degrades just that field
to null instead of bubbling to a 500; wrap each message.textContent /
message.dataContent access in a small try-catch (or use runCatching { …
}.getOrNull()) and on failure return null for that field, keeping the rest of
the row and the overall paged list / GET /messages/{id} response intact.

app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt (2)

83-93: ⚠️ Potential issue | 🟠 Major

Guard these computed accessors against bad stored payloads.

MessagesRoutes.toDomain() now reads these properties on both the list and detail endpoints. If any row has content that does not match the declared type, fromJson will throw here and turn the whole response into a 500. Catch parse failures here and return null/fallback per record instead of letting one bad row break the endpoint.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt` around lines
83 - 93, The computed accessors textContent and dataContent currently call
gson.fromJson(...) directly and will throw on malformed content; wrap each
gson.fromJson call in a try-catch that catches JSON parse exceptions (e.g.,
JsonSyntaxException/JsonParseException/RuntimeException) and returns null on
failure so a single bad payload doesn't raise a 500; modify the getters for
textContent and dataContent to perform parsing inside the try block and return
null in the catch, leaving other behavior unchanged.

---

89-100: ⚠️ Potential issue | 🔴 Critical

Use a configured Gson for MessageContent.Data.

MessageContent.Data.port is UShort, but this companion still uses a bare Gson(). Gson does not deserialize Kotlin unsigned types out of the box, so dataContent will fail at runtime for stored data messages until a UShort adapter or equivalent configured builder is used.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/me/capcom/smsgateway/data/entities/Message.kt` around lines
89 - 100, The current private gson in the Message companion uses a plain Gson
which cannot deserialize Kotlin unsigned types (so Message.dataContent ->
MessageContent.Data with UShort port will fail); replace the bare Gson() with
the app's configured Gson instance or build a Gson via GsonBuilder that
registers a UShort type adapter/serializer (or reuse an existing Gson provider)
and assign it to the companion object's gson so Message.dataContent correctly
deserializes MessageContent.Data.port; update the companion's private val gson
accordingly (referencing the companion object, gson, dataContent and
MessageContent.Data symbols).

app/src/main/assets/api/swagger.json (1)

1279-1284: ⚠️ Potential issue | 🟠 Major

Document how clients supply the refresh token.

The operation says it refreshes "with specified refresh token", but there is no request body, parameter, or distinct security scheme—just the same JWTAuth header used by normal authenticated calls. As written, clients cannot tell whether this endpoint expects an access token or a refresh token in Authorization.

Also applies to: 1488-1547

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/assets/api/swagger.json` around lines 1279 - 1284, The OpenAPI
entry for JWTAuth (name "Authorization", type "apiKey") doesn't explain how the
refresh endpoint receives the refresh token; update the refresh operation to
explicitly accept a refresh token either by (a) adding a distinct security
scheme such as "RefreshTokenAuth" (in header or cookie) and reference it in the
refresh operation's security requirement, or (b) adding a request parameter/body
parameter named "refresh_token" (string) to the refresh operation and clarifying
in its description that the Authorization header still expects the access token
while the refresh_token parameter carries the refresh token; ensure the
operation's description and schema reference "JWTAuth" and the new
"RefreshTokenAuth" or "refresh_token" param so clients know which token goes
where.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes