[Bug] Notification action buttons from the Mac app never fire — empty "text" is treated as an inline reply

[renatoaraujoc]

Describe the bug

Tapping any plain action button on a synced notification in the macOS app — "Mark as read" on Spark, "Play" on the YouTube media notification, "Mark as read"/"Mute" on WhatsApp — does nothing on the phone. The Mac reports the action as sent and the frame does reach the device, but the action never runs.

I traced it to how the reply text is read on the Android side. In WebSocketMessageHandler.kt:396:

val replyText = data.optString("text")

The Mac only includes text when there actually is a reply (WebSocketServer+Outgoing.swift):

var data: [String: Any] = ["id": id, "name": name]
if let t = text, !t.isEmpty { data["text"] = t }

So for a plain button the field is absent and optString returns "", not null. That empty string is handed to performNotificationAction(), where the path is chosen at NotificationDismissalUtil.kt:135:

if (replyText != null) {

"" is non-null, so every plain button goes down the inline-reply path, finds no remoteInputs, logs Action '<name>' does not support reply on <id> (line 139) and returns false. The else branch that would actually send the action's PendingIntent is unreachable for anything arriving over the WebSocket.

To Reproduce

1. Connect the phone to the Mac app
2. Receive a notification that has a plain action button (e.g. Spark "Mark as read")
3. Click that button in the Mac app
4. Nothing happens on the phone; logcat shows Action '...' does not support reply on ...

Expected behavior

The action's PendingIntent fires, the same as tapping the button on the phone.

Suggested fix

Normalize the empty string when reading it:

val replyText = data.optString("text").takeIf { it.isNotEmpty() }

or change the guard in performNotificationAction() to if (!replyText.isNullOrEmpty()).

Environment

• Device: Samsung Galaxy Z Fold7 (SM-F966B)
• Android Version: 16
• App Version: 4.0.0 (versionCode 30) — Mac app 4.0.0

Additional context

Media controls over the same WebSocket work fine, so the transport and the incoming handler are healthy (I also confirmed with tcpdump on port 6996 that the frames leave the Mac when the button is clicked). Dismissing a notification that was posted after the last app start also works, which narrows this down to the action path specifically. Reply actions presumably work, since those do carry text.

[renatoaraujoc]

One related gap I ran into while fixing this: BleTransportBridge.handleNotificationAction() parses id and actionName out of the payload but drops parts[2], so inline replies never make it through over BLE. Plain buttons work there because the 2-arg call leaves replyText at its null default — which is also what confirms the simple-button branch itself is fine, it just wasn't reachable from the WebSocket path.

Both are handled in #138.