zadam/trilium
1
1
Fork 0
mirror of https://github.com/zadam/trilium.git synced 2025-01-17 04:27:56 +08:00
Code Issues Projects Releases Packages Wiki Activity

put back waiting for sync after frontend API backend request

Browse source
This commit is contained in:
zadam 2021-02-22 22:43:54 +01:00
parent 90c6852423
commit 93d55b3e7b
2 changed files with 3 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
src/public/app/services/frontend_script_api.js
View file

@ -166,9 +166,7 @@ function FrontendScriptApi(startNote, currentNote, originEntity = null, $contain
}, "script"); }, "script");
if (ret.success) { if (ret.success) {
// we used to wait for max entity change here returned from the response await ws.waitForMaxKnownEntityChangeId();
// but it's too easy to end up in infinite cycle when this is triggered as a consequence of
// sync event (typically from custom widget)
return ret.executionResult; return ret.executionResult;
} }

3
src/public/app/widgets/note_tree.js
View file

@ -1130,7 +1130,8 @@ export default class NoteTreeWidget extends TabAwareWidget {
// here note tree is responsible for updating global state of the application // here note tree is responsible for updating global state of the application
// this should be done by tabcontext / tabmanager and note tree should only listen to // this should be done by tabcontext / tabmanager and note tree should only listen to
// changes in active note and just set the "active" state // changes in active note and just set the "active" state
await appContext.tabManager.getActiveTabContext().setNote(nextNotePath); // We don't await since that can bring up infinite cycles when e.g. custom widget does some backend requests which wait for max sync ID processed
appContext.tabManager.getActiveTabContext().setNote(nextNotePath);
} }
} }