Notifications: restore the sound on the extension's fallback notifications

[mpretty-cyro]

Reported twice this week (#28249, #28223): no sound on incoming message notifications, on iOS, with everything configured correctly — system notifications on with sounds enabled, Fast Mode on, a sound selected, "Sound when App is open" on.

The bug

NotificationServiceExtension.swift never sets a notification sound. The string sound does not appear in the file at all.

The extension has one path that builds content through the shared NotificationContent.toMutableContent(shouldPlaySound:) — that one attaches a sound correctly and is unaffected. It also has two paths that hand-roll a UNMutableNotificationContent, setting title, body, userInfo and badge but never sound:

Path	What the user sees	Sound
handleFailure	"Session" / "You've got a new message"	none set
handleFailureForVoIP	"Session" / "<name> is calling…"	none set

There is nothing to inherit from the payload either: it carries only spns and enc_payload (PushNotificationAPI.swift:146,150), and the sound preference lives in libSession locally and is never transmitted, so the server could not set the right one even in principle.

handleFailure is the default: arm of handleError, so any unrecognised error lands there. A user whose messages consistently fail to process in the extension gets a visible but silent notification for every single message, with nothing in the app's settings to explain it. The incoming call case is the worse of the two.

handleFailure already fetched notificationSettings for previewType and simply never read .sound.

This was fixed once already

• ecf92ceeea (2021-10-19) — "fix PN sound settings not applying to remote PNs" — added notificationContent.sound = OWSSounds.notificationSound(for: thread).notificationSound(isQuiet: false).
• a68ed28a7a (2022-03-09) — "Merge branch 'dev' into voice-calls-2" — dropped it. Not a decision: the other branch had rewritten the same delivery block and resolving in its favour removed the one line it had never had.

Gone ever since — zero occurrences in 2.0.0 through 2.15.4. The 2025 refactor restored a different mechanism (the shared presenter) covering the success path, and rebuilt the fallback paths from the post-merge shape.

That history is also why this is a named applyNotificationSound(to:notificationSettings:) rather than an assignment repeated at each call site. A bare content.sound = ... in the middle of a block someone else is rewriting is precisely what went missing last time; a missing call to a named function is conspicuous in a way a missing assignment is not.

Second, smaller fix

Preferences.Sound.notificationSound(isQuiet:) guards on filename() being nil to fall back to UNNotificationSound.default — but .default returns "", not nil. The guard never fired, the fallback was unreachable, and it built UNNotificationSound(named: ""), which resolves to no file and plays nothing.

Not reachable through the UI today (.default isn't offered in the sound picker, and libSession decodes a stored 0 to .note), so it's a latent trap rather than a live bug — but the fallback paths now depend on this function resolving correctly, so it's fixed here. Happy to split it out if you'd rather.

Testing

The extension has no test target, so the regression tests cover the sound resolution and NotificationContent in SessionMessagingKitTests instead. Added to NotificationsManagerSpec rather than a new file to avoid touching the project file.

• Verified the .default test fails against the unfixed code and passes with it.
• SessionMessagingKitTests passes in full.
• ** BUILD SUCCEEDED ** for the Session scheme.

The handleFailure / handleFailureForVoIP changes themselves are not covered by an automated test — worth saying plainly. Manual verification needs a device on a production signing cert (third-party contributors can't exercise push at all, per BUILDING.md).

Still open on the tickets

This is a confirmed defect and worth fixing regardless, but it is not yet confirmed to be what the two reporters are hitting. The question that settles it is whether their notifications read "You've got a new message" or show the sender's name and message text — if the latter, the success path ran, a sound was attached, and something else is going on. I'll update once they reply.

Draft until then.