-
-
Notifications
You must be signed in to change notification settings - Fork 609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't do /keys/changes on incremental sync #625
Changes from 3 commits
4f17352
727ad57
a0578ef
3d1fcc6
facfcf6
5a23927
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -146,18 +146,23 @@ export default class DeviceList { | |
* The actual save will be delayed by a short amount of time to | ||
* aggregate multiple writes to the database. | ||
* | ||
* @param {integer} delay Time in ms before which the save actually happens. | ||
* By default, the save is delayed for a short period in order to batch | ||
* multiple writes, but this behaviour can be disabled by passing 0. | ||
* | ||
* @return {Promise<bool>} true if the data was saved, false if | ||
* it was not (eg. because no changes were pending). The promise | ||
* will only resolve once the data is saved, so may take some time | ||
* to resolve. | ||
*/ | ||
async saveIfDirty() { | ||
async saveIfDirty(delay) { | ||
if (!this._dirty) return Promise.resolve(false); | ||
if (delay === undefined) delay = 500; | ||
|
||
if (this._savePromise === null) { | ||
// Delay saves for a bit so we can aggregate multiple saves that happen | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this comment probably needs to move up now |
||
// in quick succession (eg. when a whole room's devices are marked as known) | ||
this._savePromise = Promise.delay(500).then(() => { | ||
this._savePromise = Promise.delay(delay).then(() => { | ||
console.log('Saving device tracking data at token ' + this._syncToken); | ||
// null out savePromise now (after the delay but before the write), | ||
// otherwise we could return the existing promise when the save has | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -444,6 +444,22 @@ Crypto.prototype.getStoredDevice = function(userId, deviceId) { | |
return this._deviceList.getStoredDevice(userId, deviceId); | ||
}; | ||
|
||
/** | ||
* Save the device list, if necessary | ||
* | ||
* @param {integer} delay Time in ms before which the save actually happens. | ||
* By default, the save is delayed for a short period in order to batch | ||
* multiple writes, but this behaviour can be disabled by passing 0. | ||
* | ||
* @return {Promise<bool>} true if the data was saved, false if | ||
* it was not (eg. because no changes were pending). The promise | ||
* will only resolve once the data is saved, so may take some time | ||
* to resolve. | ||
*/ | ||
Crypto.prototype.saveDeviceList = function(delay) { | ||
return this._deviceList.saveIfDirty(delay); | ||
}; | ||
|
||
/** | ||
* Update the blocked/verified state of the given device | ||
* | ||
|
@@ -811,27 +827,18 @@ Crypto.prototype.decryptEvent = function(event) { | |
*/ | ||
Crypto.prototype.handleDeviceListChanges = async function(syncData, syncDeviceLists) { | ||
// Initial syncs don't have device change lists. We'll either get the complete list | ||
// of changes for the interval or invalidate everything in onSyncComplete | ||
// of changes for the interval or will have invalidated everything in willProcessSync | ||
if (!syncData.oldSyncToken) return; | ||
|
||
if (syncData.oldSyncToken === this._deviceList.getSyncToken()) { | ||
// the point the db is at matches where the sync started from, so | ||
// we can safely write the changes | ||
this._evalDeviceListChanges(syncDeviceLists); | ||
} else { | ||
// the db is at a different point to where this sync started from, so | ||
// additionally fetch the changes between where the db is and where the | ||
// sync started | ||
console.log( | ||
"Device list sync gap detected - fetching key changes between " + | ||
this._deviceList.getSyncToken() + " and " + syncData.oldSyncToken, | ||
); | ||
const gapDeviceLists = await this._baseApis.getKeyChanges( | ||
this._deviceList.getSyncToken(), syncData.oldSyncToken, | ||
); | ||
this._evalDeviceListChanges(gapDeviceLists); | ||
this._evalDeviceListChanges(syncDeviceLists); | ||
} | ||
// Here, we're relying on the fact that we only ever save the sync data after | ||
// sucessfully saving the device list data, so we're guarenteed that the device | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. guaranteed There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. done |
||
// list store is at least as fresh as the sync token from the sync store, ie. | ||
// any device changes received in sync tokens prior to the 'next' token here | ||
// have been processed and are reflected in the current device list. | ||
// If we didn't make this assumption, we'd have to use the /keys/changes API | ||
// to get key changes between the sync token in the device list and the 'old' | ||
// sync token used here to make sure we didn't miss any. | ||
this._evalDeviceListChanges(syncDeviceLists); | ||
}; | ||
|
||
/** | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit concerned that, if there is already a save scheduled, it might not happen for 500ms even if delay is 0. can you reorganise this somehow so that it will happen immediately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering whether this was worth worrying about. Have added it (although since Promise.delay can only be left to run or canceled outright, it's all had to change to a setTimeout)