record, report, and notify about olm errors #1146
Conversation
There was a problem hiding this comment.
lgtm I think! I think we do also have stores that are just not implemented in the localstorage / memory stores so you probably could have got away with just writing the indexeddb one and leaving the rest as stubs. People in firefox private mode appreciate your efforts. :)
| } | ||
| problems.sort((a, b) => { | ||
| return a.time - b.time; | ||
| }); |
There was a problem hiding this comment.
fwiw you can have multi-level indices on indexeddb now*, so you would be able to index by timestamp, although not 100% sure if you would be able to get the largest ts lower than the given ts. Hopefully this table won't be big enough that it's a problem in terms of efficiency although if we ever want the index in future then could it be useful to add it now to avoid db changes?
*they might still not be supported on Edge but we already have other tables that use them
There was a problem hiding this comment.
I did take a look at it, but didn't see an easy way to do the query that I needed.
Implements the
no_olmpart of MSC2399, and tells the user when the olm session got wedged.The general algorithm is that when there's a problem with the olm session (either it's wedged, or the sender tells us they can't establish a session), then we try to recover by creating a session ourselves. Then we record the problem, timestamp, and whether we (think we) fixed the problem. When we have a megolm event that we can't decrypt, we check if it was sent within the time that we had a problem, and if so, tell the user what the problem was, and whether we were able to fix it.