Open dawnmist opened 1 year ago
Hey, @dawnmist, cheers for the report!
Did you see this in 4.9 / previously?
Do you have a schema that you can share - I'm curious as to how big the schema was as well, and can you provide further insight into whether this was when you were doing something specific? it seems like just a regular formatting attempt based on the error -- ah sorry, I think my brain skimmed over, just saw that this includes formatting, linting, autocompletion!
It would also help if you just see this through vscode or if you also get an error when going through the cli npx prisma format
I am new to using Prisma, so I hadn't used it prior to 4.10.
I was setting up an initial schema for a supabase db with auth & storage and learning about prisma as I was doing so, so I was doing a large amount of editing to create that initial schema as I was going along. It was most definitely time/volume of edits related, as it would start to happen after 2-3 hours of continual edits with breaks to read docs/look up information during that time.
Basically, all vscode attempts at linting/formatting/autocomplete would end up becoming blocked, no further interaction with the prisma extension would be possible until vscode were restarted (I don't know of a way to restart an extension without having to restart vscode).
Since getting the bulk of the schema sorted out so that I'm not spending hours editing the schema at once it's ceased happening, further indication that it genuinely is time/number of edits related (potential memory leak).
The final schema is ~960 lines, with at least 1/3 of that being the original supabase auth/storage tables.
I've uploaded an earlier copy of the schema file to https://www.dropbox.com/s/q455kxz08cnsles/schema.prisma?dl=0 - it still has some errors such as forgetting to map names from camel-case to snake case for db names/some of the relationships are not properly thought out, but was one of the versions of the schema where I was seeing this issue crop up while revising it heavily. I'd appreciate it if you could let me know once you've grabbed it so I can take the file down again.
Hey, cheers, got it now! Hm, so then it also sounds like the issue disappeared after re-starting the extension as well. Did you try the CLI at all?
The cli was working fine for doing db pull/migrate tasks - but that was as a separate process rather than within the extension's active process.
Each time the extension started throwing memory access out of bounds errors, restarting VSCode would "fix" the issue for the next 2-3 hours, then the memory errors would begin again completely locking up the extension from working until VSCode was again restarted.
I think I restarted VSCode at least 5 times due to this issue on the day that I originally posted this bug report. That was also the day that version 4.11 was released, so I got to test in both the version I'd had initially and in the newly released version.
Yeah, no worries, just trying to narrow down if this is an issue within the language-tools repo itself or our internal prisma-fmt
engine which is what handles the actual formatting :)
I've got your schema up in another vscode instance in the background and occasionally making minor updates, saving, formatting, quick-fixes. I am noticing a slight slowdown already (I think it's been about an hour and a half maybe two hours now) but not noting the errors yet.
prisma-fmt
is still yielding expected results of formatting within 17-21ms so the delay is occurring elsewhere π€ (per the cli command)
It's been a few hours now of random edits here and there and I still can't seem to replicate this. The most I can get is the occasional 3-4 sec delay (when left for a bit) in the cli which is I think just cold-start as a re-run does not then have the same issue. Not noting any delays when running the formatter through vscode.
OS: MacOS :: darwin-arm64 Editor: VSCode 1.76.1 Extension version: 4.11.0
[Error - 2:24:48 PM] [object Object]
is super not helpful here tho, I'll see if I can't improve that in the meantime so we can get better logging here π
Going through my VSCode settings in case that is a contributing factor, these are the ones most likely to be of relevance (the rest are either generic font/colour/line length, or are specific to particular extensions):
{
"editor.codeActionsOnSave": {
"source.organizeImports": false,
"source.fixAll": true,
"source.fixAll.eslint": true
},
"editor.formatOnSave": true,
"editor.formatOnType": true,
"editor.formatOnPaste": true,
"editor.suggest.showMethods": true,
"editor.suggest.preview": true,
"editor.acceptSuggestionOnEnter": "on",
"editor.tabSize": 2,
"editor.wordWrapColumn": 100,
"editor.renderWhitespace": "boundary",
"editor.snippetSuggestions": "bottom",
"emmet.excludeLanguages": [
"markdown",
"typescript",
"typescriptreact"
],
"emmet.showExpandedAbbreviation": "inMarkupAndStylesheetFilesOnly",
"prisma.fileWatcher": true
}
my usage in comparison
{
// "editor.codeActionsOnSave": {}, don't have this
"editor.formatOnSave": true,
// "editor.formatOnType": true, don't have this
// "editor.formatOnPaste": true, don't have this
"editor.suggest.showMethods": true,
"editor.suggest.preview": true,
// "editor.acceptSuggestionOnEnter": "on", don't have this
// "editor.tabSize": 2, I don't have this but I use spaces (2) in .prisma files
// "editor.wordWrapColumn": 100, don't have this
// "editor.renderWhitespace": "boundary", don't have this
// "editor.snippetSuggestions": "bottom", don't have this
// "emmet.excludeLanguages": [], don't have this
// "emmet.showExpandedAbbreviation": "inMarkupAndStylesheetFilesOnly", don't have this
// "prisma.fileWatcher": true, I don't have this, I wonder if this is it
}
The file watcher is quite likely - between it and the format on type/paste the extension is actively working a lot of the time (I'd generally only seen the activity when the extension log window popped up due to it throwing the memory error, and it seemed at that point to be attempting formatting/lookups on every keystroke).
I must say that I've found the prisma extension absolutely awesome to work with apart from this memory issue - it certainly helped a lot with learning prisma syntax and how to write relationships/etc. It's definitely been one of the nicest language servers that I've worked with. :)
I must say that I've found the prisma extension absolutely awesome to work with apart from this memory issue - it certainly helped a lot with learning prisma syntax and how to write relationships/etc. It's definitely been one of the nicest language servers that I've worked with. :)
Really appreciate that! Doing my best to make it even better π
The file watcher is quite likely - between it and the format on type/paste the extension is actively working a lot of the time (I'd generally only seen the activity when the extension log window popped up due to it throwing the memory error, and it seemed at that point to be attempting formatting/lookups on every keystroke).
Yeah, I'll see about having another bash with the filewatcher and other format settings enabled :) Cheers again for being so communicative! :D
Bug description
I'm in the process of designing a new schema/db. After editing the schema.prisma file for a couple of hours (with breaks to look up documentation/etc), the Prisma Language Server starts throwing "memory access out of bounds" errors on every attempt to format/lint/autocomplete.
Restarting VSCode so that the Prisma Language Server gets restarted will allow linting/formatting again for another couple of hours before the Prisma Language Service starts throwing the memory access errors again.
I have tested this on both version 4.10.1 and 4.11.0 - both run into the same memory access errors after a few hours.
VSCode Extension version 4.10.1 and 4.11.0
How to reproduce
Steps to reproduce the behavior:
Expected behavior
The Prisma Language Server should not start failing on all access due to memory issues.
Prisma information
This occurs when editing the schema file itself.
Environment & setup
Prisma Language Server log from a few lines before the errors started: