This is a leftover from a feature that we had https://github.com/CommE2E/comm/commit/d967a4423104140388fb8227787f676abf319dd0

Modify convertOpsToClientDBOps

In D11936#342562, @kamil wrote:

Wondering if updating convertOpsToClientDBOps to handle nullable param wouldn't be even more readable but up to you

In D11931#342559, @kamil wrote:

Are you planning to update callsites of processDBStoreOperations to use SQLiteAPI?

It might be a good idea to have a sanity check in a test plan to verify if the responses are validated correctly (if sending and receiving responses from keyserver work, for a couple of endpoints).

Fix imports

In D11923#341468, @marcin wrote:

Checked if persisting drafts still works.

Same suggestions to test plan as for parent diff.

In D11922#341463, @marcin wrote:

Checked if persisting drafts still works.

Why only drafts? We can probably test other stores by making changes in the app, closing keyserver connection and restarting it afterwards. I would also run sth like git grep "commCoreModule.process" before and after applying this diff.

Add imports

Wondering if there's a pattern in choosing which validators were moved together in a diff.

I planned changes because I thought there was an issue with the current users - they are already registered, so we won't put the version into the DB for them and their backup won't contain it. Actually, there's no such problem, because in order to create a backup, the app should be run, and the migration from the previous diff will be performed and will put the version into the DB.

flow + close reading for now

Sounds risky for a change that changes the flow.

This code is almost entirely a copy-paste from existing endpoints. Can we reduce the duplication?

Thanks for making this change!

I considered specifying this on the message specs, but there's no way to do that without leading to an import cycle.

It would be great if we could make a corresponding change to RawUnsupportedMessageInfo type (update unsupportedMessageInfo). Maybe we can define this type in another / new file? The problem with the current solution is that we have to remember to update the validator and our types don't protect us against forgetting about this.