Improvement: use the same functions to fetch and persist olm data regardless of notification type (keyserver/peer device)

Use transactional write when creating outbound session

Even if we don't use localforage in our code outside of web, this patch probably affects some transitive dependencies for other projects. It looks like it's backwards-compatible, so it should be safe. But we may face some trouble at a later point if a transitive dependency upgrades its version, depending on which package Yarn hoists to the workspace root, and how patch-package handles it when multiple versions of a package are present (does it patch all of them, or only the one at the workspace root?)

I wonder if we should have a separate task for updating the replies count. I don't think I contemplated it in sendTextMessageSpec

Looks like CommTest passes – would love to get another accept from either reviewer before landing, to confirm that this new strategy seems safe

Try ignoring all *.tfstate and *.tfvars files

In D12831#363248, @bartek wrote:

Accepting, but I noticed one more thing that needs to be considered.
Scan operation doesn't always return all items. It has response limit of 1MB. If it's exceeded, the response contains LastEvaluatedKey property, from which we should start a subsequent scan.

On the other hand, this table is relatively small (1k items, ~60kB) so it's far from the limit. And it's not expected to grow, so we could ignore the issue as well

AWS Docs: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Scan.html

Rebase

Rebase

Move code

It makes sense for the sidebar creation use case that I designed for, which is where this hook will be used. I don't think you'll want to use this particular hook, but I can see how for the search use case, it might make sense to replace getRelatedMessages with an API that can query a batch of message IDs at once. I haven't considered the performance implications here – would be good for you and @kamil to consider this, and make a decision on whether the API needs to be replaced

A couple of changes

If the patch file appears cumbersome to review I will create fork of localforage with PR containing those changes.

On the keyserver, when reactionMessageCreationResponder is called, it calls createMessages which in turn calls updateRepliesCount. Do we need to do something like this for DMs?

This solution requires us to query for every message separately. This seems very inefficient. Is this necessary?

Makes sense! I asked about it in https://phab.comm.dev/D12655#362785.

Accepting, but I noticed one more thing that needs to be considered.
Scan operation doesn't always return all items. It has response limit of 1MB. If it's exceeded, the response contains LastEvaluatedKey property, from which we should start a subsequent scan.

Nice!

Rebase

Rebase