At start of sn-scriptsync plugin non-actual versions of scripts were saved to instance
PZifcakBC opened this issue · 7 comments
At start of sn-scriptsync plugin non-actual versions of scripts were saved to instance
- Some of the files were in theirs actual versions, so update did not save them
- Some of the files were from different scope, so the attempt for save was not successfull
- Two of files were not actual and this case the old versions from vscode were saved and owerwrite most current version in instance
I am "almost sure", that
- I have not invoked Save all
- Some of the files which were tried to safe were not open at all
Can you check this setting?
Maybe an external change of the file?
**Editing outside VS Code**
While you have sn-scriptsync running, you can edit files outside VS Code as well.
In this case sn-scriptsync acts as a proxy and will pass the changes to the instance, when saving a file.
This function can be disabled/enabled via the settings or command toggleWatchFileSystem (New in version 1.9)
I am "almost sure", that
- I have not invoked Save all
- Some of the files which were tried to safe were not open at all
- Neither of files was edited outside the VS Code, although the sn-scriptsync: Watch File System is enabled, I do not think this was the root cause
As a workaround I will clean the workspace before each editing session to prevent such surprise.
It there any log which I can find and send you so you would have better chance to find out what happened and why?
From the screenshot it is apparent that all the attempts for save almost immediatelly followed the opening of SN ScriptSync Helper Tab invoked by clicking the floppy disc icon next to CSAS_ARS_EntityUtils Script Include's script.
I have adjusted the way the filewatcher works.
A issue was that a file overwritten from the instance, was immediately posted back.
Besides, now you can see the save source, either FileSystem or VS Code.
I do not do other logging.
Last change is that the switching of FileSystemWatcher is now improved.
To be clear the Saved To ServiceNow at 19:35:43 is now prevented.
Please test and let me now if this fixes the problem.
Be sure to get sn-scriptsync 1.9.2 and SN Utils 4.2.2.2
Hi Arnoud, thank you for quick response and reaction.
I just did some quick checks as I have not much time to test all the possible scenarios.
I have not discovered any unexpected behavior related to attempts for saving old versions from VS Code to SN.
What I do not understand is why there are multiple lines saying Saved to ServiceNow from FileWatcher, while I saved file within VS Code, not outside it.
Because VS Code is my only editor for now, I will turn the sn-scriptsync: Watch File System property off anyway.
Great work you are doing with SN Utils and sn-scriptsync!
I did do another minor improvement, if you have some time, could you check.
Anyhow, indeed best to switch of filesync.
I have not recognized any unwilling attempts for save in 1.9.4, on the contrary, it seems that Watch FS is not saving changes made outside VS Code to the instance.
If Watch FS is turned off and changes are saved within VS Code, only one message about saving to instance is logged and changes are saved indeed.
f Watch FS is turned on and changes are saved within VS Code, only one message about saving to instance is logged and changes are saved indeed.
If Watch FS is turned on and changes are saved outside VS Code, random number of messages (noticed 2 - 4) is logged and changes are not saved to the instance.
NB I have not restarted VS Code after changes of Watch FS.
Im removing the filesystem watcher in 1.9.5, its causing more harm then good...