If you take my advice in D4231, this check will need to be updated to a boolean

So the plan for now is to update this, since it is safe outside of UNNotificationAppExtension? And later when we implement it inside UNNotificationAppExtension, we will do something different I assume (eg. ENG-1218)

Actually I do not think that keeping this logic here is related to NotificationService at all. To move this logic from here to NotificationService we would need:

1. To write to SQLite from NotificationService
2. To be able to process rescinds via notification filtering mechanism.

At this moment we will probably use NotificationService to write to some other storage that will be processed in JS when the app starts. The code above is executed outside of JS, so we would simply overwrite unread status twice. Additionally this will only happen once we get ability to filter notifications.

Makes sense! Thanks for explaining

It is not optional field on the keyserver side. I am not against ensuring existence of threadID key, but then we would need also to ensure that backgroundNotifTypeKey exists since it is put in the notification via the same mechanism as threadID

Kind of, but backgroundNotificationTypeKey is compared to e.g. CLEAR so if it isn't present, the behavior would be the same as if it was present but had a different value.

Historically we've assumed that we launch keyserver changes based on codeVersion, eg. if my comment here is heeded than we should be okay. That said, it's true that @palys-swm's suggestion would make this safer