After a quick research I found that using Codable API in OBJ-C requires some bridges with Swift: https://stackoverflow.com/questions/50617542/how-to-use-codable-protocol-in-objective-c-data-model-class. Additionally I am not sure how stable is the current structure of the rescind payload - how likely are we to be changing it in future. Using Codable would require us to declare class with fixed attributes, so each change in rescind payload on the JS side would require a change in this class. This increases the coupling in the codebase. However, once we reach a point where notifications payload structures are unlikely to change we might consider representing them in native languages as more rigid and restrictive types rather than just dictionaries mapping String -> Object.

In this particular case, if we ignore the error we will eventually pull the correct state of thread unread status from keyserver. Currently updating SQLite in response to notifications is a kind of redundancy that can be helpful when user opens the app in weak network environment but they still got the correct state because of received notifications. From the user perspective, killing the app here would be a poor experience (in worst case they would still get the correct state but just later). But from the dev perspective it might be useful since having an error here means that some error occurred on the NSE side since it failed to correctly persist rescind payload (it could be time out for example). This would make us investigate what had happened on the NSE side.
It is high time this issue is taken on: https://linear.app/comm/issue/ENG-2670/c-equivalent-of-dev-flag

Every where in our codebase where we create std::string from NSString* we call UTF8String method before passing it to std::string constructor. Apple docs suggest to do it this way: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Strings/Articles/CreatingStrings.html

This answer: https://stackoverflow.com/a/5503357 nicely explains how capturing and mutability works in C++ lambdas. This lambda has to be mutable since the inner function: comm::ThreadOperations::updateSQLiteUnreadStatus(threadID, false) takes threadID be reference.

This TODO was introduced here: https://phab.comm.dev/D3162. I am pretty sure that this TODO was automatically added when NotificationService.mm file was generated, but I will check with @tomek about this. Nevertheless I don't see any reason to remove this TODO until we actually put there some code that handles notification decryption and modifies self.bestAttemptContent.

It would be a good measure.

According to the keyserver code messageInfos field is never introduced to rescind payload and I can't imagine why would we do so. However technically no type system or unit tests prevent us from inserting this field in future. cc @atul, @ashoat - is it ever possible that rescind might have messageInfos field?

No, I don't think this is possible

Therefore I assume it is safe early return here once messageInfos content is persisted.