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
11 months 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
11 months 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
11 months 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
6 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
2 weeks 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: