This is a leftover from a feature that we had https://github.com/CommE2E/comm/commit/d967a4423104140388fb8227787f676abf319dd0
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 15 2024
May 14 2024
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?
May 13 2024
May 10 2024
May 9 2024
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
May 8 2024
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.
May 7 2024
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!
May 6 2024
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.