Open bpmct opened 3 years ago
lostintangent
commented
3 years ago Hmm, that's no good. Thanks for reporting this! Just to confirm: you only see this issue after leaving a gist file open for a while and then trying to edit it? If you closed the file and then re-opened/edited it, does syncing work fine?
bpmct
commented
3 years ago Closing and re-opening the gist does not seem to resolve the issue. It maintains the local copy but never syncs
lostintangent
commented
3 years ago If you refresh the gist tree, does that resolve the issue? And also, just to confirm: is this related to a file in a gist as opposed to a file in a GistPad-managed repo?
bpmct
commented
3 years ago This is related to a file in a gist. I was able to replicate it again by leaving my window open for ~ 30 minutes. Hitting the refresh button does not work as well as closing and opening the file. I noticed that the linting does not work also. When I try to close, I run into this.
Were the logs I provided helpful?
bpmct
commented
3 years ago @lostintangent anything I can help with this?
disco0
commented
3 years ago I've had similar output in my Window log for awhile, possibly a few months even—I can't remember it correlating with saving (or when it even started for that matter) but during regular Code usage a few sections in output log errors with the same description, if not code location as well:
whilp
commented
2 years ago FWIW, I see this consistently when editing gists using eg vscode.dev. As the original reporter described, everything works great for a bit, but then updates no longer commit. If I refresh vscode.dev, whatever work was in progress is lost. When this happens during eg notebook development (w/ vscode-pyodide), use GistPad to create a new file, copy the current notebook cells to it, delete the old file, and rename the new file to get back in business.
carlocardella
commented
2 years ago @bpmct, @whilp, can you still repro with the latest GistPad version?
joewelds
commented
1 year ago @carlocardella I am experiencing this on v0.4.1. Started yesterday for me.
2022-12-02 14:47:21.392 [error] [vsls-contrib.gistfs] provider FAILED 2022-12-02 14:47:21.393 [error] TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator)) at c.provideDocumentLinks (c:\Users\saw\.vscode\extensions\vsls-contrib.gistfs-0.4.1\dist\extension.js:51:187540) at ke.provideLinks (c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:94:61193) at c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:94:79984 at ne._withAdapter (c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:94:67325) at ne.$provideDocumentLinks (c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:94:79961) at l._doInvokeHandler (c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:102:13680) at l._invokeHandler (c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:102:13362) at l._receiveRequest (c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:102:12081) at l._receiveOneMessage (c:\Users\saw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:102:10834)
julienadam
commented
1 year ago @carlocardella Can confirm too, this is happening right now after about 30 minutes of editing with the same exact error in the Extension Host window log. It started happening a few days ago but I didn't realize and unfortunately lost quite a bit of work, not a big deal but still annoying.
I tried refreshing the gist with the Refresh Gists command, it didn't solve the issue.
I couldn't find any temp or cached files to recover in Roaming/Code or elsewhere. If there are any, I would love to know where I can find.
Incidentally, #266 would be really great for backup purposes !
Here's the log :
2023-09-23 12:51:09.395 [error] [vsls-contrib.gistfs] provider FAILED
2023-09-23 12:51:09.395 [error] TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
at o.provideHover (c:\Users\XYZ\.vscode\extensions\vsls-contrib.gistfs-0.4.1\dist\extension.js:51:186858)
at d.provideHover (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:109:40778)
at c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:109:66661
at he.t (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:109:64110)
at he.$provideHover (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:109:66650)
at i.N (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:116:10813)
at i.M (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:116:10579)
at i.H (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:116:9621)
at i.G (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:116:8736)
at n.value (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:116:7566)
at m.w (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:63:1902)
at m.fire (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:63:2119)
at w.fire (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:79:13940)
at n.value (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:135:7901)
at m.w (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:63:1902)
at m.fire (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:63:2119)
at w.fire (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:79:13940)
at MessagePortMain.<anonymous> (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:135:6181)
at MessagePortMain.emit (node:events:513:28)
at MessagePortMain._internalPort.emit (node:electron/js2c/utility_init:2:367)I kept VS Code open and made a few more tests.
Adding a new file with the same contents in the same gist but a different name works, the new file is properly saved to the gist every time I save in the editor. The error message keeps popping up though so it might be a red herring, or an underlying issue related to the faulty file, I don't know.
Once the problem started, it affected 2 files from 2 different gists. The faulty gist files stay faulty if I close the editor tab and reopen them.
Other files from other gists I just opened are not affected. I'll wait a bit and report later, see if it's time related.
Probably unrelated but the files I had problems with were all .md markdown files.
julienadam
commented
1 year ago Still more tests.
If I rename the faulty file to something else, the problem disappears, changes are saved correctly. If I rename it back to the original name, it stops saving again. So it looks like it's related to a specific filename in a specific gist. Other files with the same filename in other gists are not affected.
When trying to exit vscode I got a popup saying "Saving editors with unsaved changes is taking a bit longer..." that I had to cancel followed by another one saying "Closing the window is taking a bit longer... The following operations are still running: - Saving text files".
After restarting VS Code, the faulty files were still faulty.
I also tried and succeeded editing the faulty file online using gist.
After that I restarted VS Code and the problem finally disappeared (could be a coincidence as another faulty gist file that I did not edit online started working again too)...
julienadam
commented
1 year ago Found possibly relevant error messages in the Runtime status tab, "Uncaught Errors" section of the extension tab. It may have been a case of too many CTRL-S in a short period of time ?
API rate limit exceeded for user ID XXXXXXX. If you reach out to GitHub Support for help, please include the request ID 4099:4064:6F46AD3:707C99E:XXXXXXX.
API rate limit exceeded for user ID XXXXXXX. If you reach out to GitHub Support for help, please include the request ID 7985:21DD:3A2B51F:3AD2BD1:XXXXXXX.Ah yeah that seems like the likely issue, and also, explains why I haven't been able to repro this. The rate limit is 5k/hour, so I may take a look and see if I can 1) reduce any unnecessary API calls, 2) do some sort of batching, and 3) provide better error reporting when the rate limit is exhausted.
christothes
commented
9 months ago I've been hitting this also - I think this is would be an issue for anyone with autosave enabled on a short delay.
One idea - allow an option to de-couple saving the doc with pushing a diff to the gist and allow it to be reconciled on doc close to avoid unintentionally not saving.
billwert
commented
3 months ago +1 to this - I get this a couple times a week when I use a gist to take live notes of a long meeting. Would love an option to not auto-push / push on close, something like that.
Describe the bug I run into an issue after editing gist where it does not update on GitHub.
To Reproduce Steps to reproduce the behavior:
Expected behavior Gists are synced to GitHub
Screenshots If applicable, add screenshots to help explain your problem.
When I try to exit
Desktop (please complete the following information):
Additional context Add any other context about the problem here.
Error in
Log -> Extension Host: