Lagging experience

Even with filewatching set to false, the LSP server process still consumes up to 50% of CPU usage, which suggests it might still be monitoring the file, causing the entire experience to lag. In contrast, when using Visual Studio Code with the same file, the CPU usage does not increase.

Yes I have also noticed that it has been slower recently... From what I can see from the code I have, it should still do what it did before I removed a hack for something the server didn't follow the spec for...
I can try to investigate when I get some time

i can try to use a old version of the server and the client, to see.

Thanks! Could you also try old version of the plugin before I removed hacks.lua?

i moved here 'fix: fix bug with sln parser', commit before 'fix: remove unnecessary hack for filewatching' and the problem is still there

and i wasnt able to use an old version of roslyn it gives me a problem.I feel the is something with the new version of roslyn but i wasnt able to test it

Came to the issues because I've been noticing the same thing recently w/ roslyn and rzls. Shamelessly plugging a small go program I just wrote for myself to help understand the lsp flow for developing on rzls.nvim. https://github.com/mparq/lsptrace in case the lsp traces can reveal anything strange that might be causing the lag.

Came to the issues because I've been noticing the same thing recently w/ roslyn and rzls. Shamelessly plugging a small go program I just wrote for myself to help understand the lsp flow for developing on rzls.nvim. https://github.com/mparq/lsptrace in case the lsp traces can reveal anything strange that might be causing the lag.

Very interesting! I will see if I can try it out. Feel free, anyone, to comment here about any potential findings. Any help would be more than welcomed!

i found issue of vscode's extention(since it uses roslyn too) that look like our problem: https://github.com/dotnet/vscode-csharp/issues/4350

I am not sure if that is the exact problem🤔 Because I feel like it has gotten super slow recently without my project necessarily growing a lot in size.
Today it has been unbearable at some point, where I needed to restart neovim and it just used all of mye CPU and my fan on my macbook pro m2 pro just started spinning up for like the first time ever

is there any info you could give for when it's slow? what is exactly slow: code editing / navigation / renferences, etc. how does it become slow, are there random spikes that make it suddenly slow, or is it gradually becoming slower over time? if so how much time does it usually take, how many buffers do you have open, etc ? anything could probably help
i've tried to reproduce this quite a bit today, but without much success. the only thing weird for me was that somehow trying to type vim commands became abnormally slow, but somehow code editing and navigation worked normally

Yeah sure!
So, it seemed to be somewhat random for me today, but it happened multiple times. I don't really have solid reproducible steps, but it seemed to happen after having edited some files for about 1 hour or so. I know I had multiple buffers open, but I am not sure exactly how many. If I were to guess I would say between 5 and 10 open buffers, but most of them just in the background
It seemed to just suddenly become slow, and then everything would basically choke. It would take several seconds before being able to type something at all, and for text to come up on the screen. Also, diagnostics were super slow.
Trying to do anything like go to definition, hover and navigation would just not work, and I would have to just wait for several seconds before it would start to slow down again. However, if I remember correctly, it seemed like it would suddenly spike again without doing too much after it had happened once.
Restarting neovim seemed to make it a lot better and then I would be able to use it for max an hour or so before it started happening again.
I looked at my CPU usage in htop, and all my cores was maxed out at 100% with roslyn taking 700-800% of CPU

in my case, it happend when i am in a big file(>1000 lines),when i try to edit it the lsp takes >10 seconds to update the warnings

Do you have a consistent reproduction? If so, I have small suspicion that some of this might be related to diagnostics.
So I am setting dynamicregistrations for diagnostics as a capability even though neovim doesn't support it. I haven't looked too much into what it means, but roslyn doesn't send any diagnostics if not. You can see in config.lua
I know that roslyn uses pull diagnostics, which means neovim is asking for diagnostics, and from what I can see, this happens on every single change.
Could it maybe be that roslyn is not discarding any previous requests for diagnostics, even though new ones are coming in? And then it needs to handle a lot at once to send diagnostics for old buffer state?
If someone has a good reproduction for this, it would be really helpful if you could share it. For example by adding a link to a project here on github and such.
If not possible, could someone for example try to disable the diagnostics by modifying the config.lua file and/or try something like this out: https://github.com/neovim/neovim/pull/30055/files
I have no idea if some of that would help, or even is the issue here, but this is what I am thinking right now

i think you got it, when i write "var a = "foo"" , i got the warning in different steps:
1)i got "v" dosnt exist
2) got "var" error....
3) "got var a = ..."
It seems that is buffering the warning

i've just tried to disable the diagnostic "vim.diagnostic.enable(false)", but still the cpu go up

with this two
	 roslyn_config.config.capabilities.textDocument.diagnostic.dynamicRegistration=true
	 roslyn_config.config.capabilities.textDocument.diagnostic.relatedDocumentSupport=true

it seems that something is speeding up(i dont know if it's my impression)

I know that roslyn uses pull diagnostics, which means neovim is asking for diagnostics, and from what I can see, this happens on every single change.

I shouldn't send requests on every change, but only after 150ms after you've stopped typing (default value for debounce_text_changes)

Could it maybe be that roslyn is not discarding any previous requests for diagnostics, even though new ones are coming in? And then it needs to handle a lot at once to send diagnostics for old buffer state?

Yes, that's true. It doesn't discard any request it doesn't receive a cancelRequest for. But both of those are pretty much true for every other LSP. I'll try a bit later to generate a few tens of thousands lines c# file to see if it becomes reproductible for me.
By the way, are the both of you using mac? I've recommended this plugin to someone using mac a few days ago and it just couldn't work because of some antivirus issues, maybe it's related somehow... My pc is almost definitely slower than a macbook pro m2 pro and it's very hard to reproduce on Windows.

I'm probably only confirming what has been already found but in case it's helpful, the trace of what I'm seeing between nvim and vscode (lines truncated to 200 chars) when I try to open the roslyn c# project itself.
it seems like vscode-csharp also sends off a bunch of diagnostic requests per keystroke, but the textDocument/diagnostic requests have extra information like identifier previousResultId, etc... whereas in nvim the requests don't have that. for nvim, the server responds after seconds whereas in vscode the responses are much more immediate.
nvim (see **FIRST DIAGNOSTIC** and **RESPONSE TO FIRST DIAGNOSTIC**):
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"p","range":{"start":{"character":8,"line":40},"end":{"character":8,"line":40}},"rangeLength":0}],"textDocument":{"version":5,"uri":"file:\/\
REQ--> [textDocument/completion] id=25  {"context":{"triggerKind":1},"position":{"character":9,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Por
**FIRST DIAGNOSTIC**REQ--> [textDocument/diagnostic] id=26  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"r","range":{"start":{"character":9,"line":40},"end":{"character":9,"line":40}},"rangeLength":0}],"textDocument":{"version":6,"uri":"file:\/\
REQ--> [textDocument/diagnostic] id=27  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"i","range":{"start":{"character":10,"line":40},"end":{"character":10,"line":40}},"rangeLength":0}],"textDocument":{"version":7,"uri":"file:\
REQ--> [textDocument/diagnostic] id=28  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 315ms [textDocument/completion] id=25  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
REQ--> [textDocument/completion] id=29  {"context":{"triggerKind":3},"position":{"character":11,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"v","range":{"start":{"character":11,"line":40},"end":{"character":11,"line":40}},"rangeLength":0}],"textDocument":{"version":8,"uri":"file:\
REQ--> [completionItem/resolve] id=30  {"insertTextFormat":1,"textEdit":{"newText":"private","range":{"start":{"character":8,"line":40},"end":{"character":9,"line":40}}},"kind":14,"data":{"ResultId":0
REQ--> [textDocument/diagnostic] id=31  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 36ms [completionItem/resolve] id=30  {"insertTextFormat":1,"data":{"ResultId":0,"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Me
<--RSP 168ms [textDocument/completion] id=29  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"a","range":{"start":{"character":12,"line":40},"end":{"character":12,"line":40}},"rangeLength":0}],"textDocument":{"version":9,"uri":"file:\
REQ--> [textDocument/completion] id=32  {"context":{"triggerKind":3},"position":{"character":13,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
REQ--> [textDocument/diagnostic] id=33  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
REQ--> [completionItem/resolve] id=34  {"insertTextFormat":1,"textEdit":{"newText":"private","range":{"start":{"character":8,"line":40},"end":{"character":11,"line":40}}},"kind":14,"data":{"ResultId":
<--RSP 2ms [completionItem/resolve] id=34  {"insertTextFormat":1,"data":{"ResultId":1,"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Met
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"t","range":{"start":{"character":13,"line":40},"end":{"character":13,"line":40}},"rangeLength":0}],"textDocument":{"version":10,"uri":"file:
REQ--> [textDocument/diagnostic] id=35  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 239ms [textDocument/completion] id=32  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"e","range":{"start":{"character":14,"line":40},"end":{"character":14,"line":40}},"rangeLength":0}],"textDocument":{"version":11,"uri":"file:
REQ--> [textDocument/completion] id=36  {"context":{"triggerKind":3},"position":{"character":15,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
REQ--> [textDocument/diagnostic] id=37  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
REQ--> [completionItem/resolve] id=38  {"insertTextFormat":1,"textEdit":{"newText":"private","range":{"start":{"character":8,"line":40},"end":{"character":13,"line":40}}},"kind":14,"data":{"ResultId":
<--RSP 7ms [completionItem/resolve] id=38  {"insertTextFormat":1,"data":{"ResultId":2,"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Met
<--RSP 230ms [textDocument/completion] id=36  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
NTF--> [textDocument/didChange] {"contentChanges":[{"text":" ","range":{"start":{"character":15,"line":40},"end":{"character":15,"line":40}},"rangeLength":0}],"textDocument":{"version":12,"uri":"file:
REQ--> [textDocument/completion] id=39  {"context":{"triggerCharacter":" ","triggerKind":2},"position":{"character":16,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src
REQ--> [textDocument/diagnostic] id=40  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 167ms [textDocument/completion] id=39  null
REQ--> [textDocument/documentHighlight] id=41  {"position":{"character":16,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Met
<--RSP 8ms [textDocument/documentHighlight] id=41  []
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"r","range":{"start":{"character":16,"line":40},"end":{"character":16,"line":40}},"rangeLength":0}],"textDocument":{"version":13,"uri":"file:
REQ--> [textDocument/completion] id=42  {"context":{"triggerKind":1},"position":{"character":17,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
REQ--> [textDocument/diagnostic] id=43  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"e","range":{"start":{"character":17,"line":40},"end":{"character":17,"line":40}},"rangeLength":0},{"text":"a","range":{"start":{"character":
REQ--> [textDocument/diagnostic] id=44  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 175ms [textDocument/completion] id=42  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
REQ--> [textDocument/completion] id=45  {"context":{"triggerKind":3},"position":{"character":19,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"d","range":{"start":{"character":19,"line":40},"end":{"character":19,"line":40}},"rangeLength":0},{"text":"o","range":{"start":{"character":
REQ--> [textDocument/diagnostic] id=46  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
REQ--> [completionItem/resolve] id=47  {"insertTextFormat":1,"textEdit":{"newText":"readonly","range":{"start":{"character":16,"line":40},"end":{"character":17,"line":40}}},"kind":14,"data":{"ResultId
<--RSP 37ms [completionItem/resolve] id=47  {"insertTextFormat":1,"data":{"ResultId":4,"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Me
<--RSP 267ms [textDocument/completion] id=45  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"n","range":{"start":{"character":21,"line":40},"end":{"character":21,"line":40}},"rangeLength":0}],"textDocument":{"version":18,"uri":"file:
REQ--> [textDocument/completion] id=48  {"context":{"triggerKind":3},"position":{"character":22,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
REQ--> [textDocument/diagnostic] id=49  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"l","range":{"start":{"character":22,"line":40},"end":{"character":22,"line":40}},"rangeLength":0}],"textDocument":{"version":19,"uri":"file:
REQ--> [completionItem/resolve] id=50  {"insertTextFormat":1,"textEdit":{"newText":"readonly","range":{"start":{"character":16,"line":40},"end":{"character":19,"line":40}}},"kind":14,"data":{"ResultId
REQ--> [textDocument/diagnostic] id=51  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 26ms [completionItem/resolve] id=50  {"insertTextFormat":1,"data":{"ResultId":5,"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Me
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"y","range":{"start":{"character":23,"line":40},"end":{"character":23,"line":40}},"rangeLength":0}],"textDocument":{"version":20,"uri":"file:
REQ--> [textDocument/diagnostic] id=52  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 305ms [textDocument/completion] id=48  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
NTF--> [$/cancelRequest] {"id":48}
NTF--> [textDocument/didChange] {"contentChanges":[{"text":" ","range":{"start":{"character":24,"line":40},"end":{"character":24,"line":40}},"rangeLength":0}],"textDocument":{"version":21,"uri":"file:
REQ--> [textDocument/completion] id=53  {"context":{"triggerCharacter":" ","triggerKind":2},"position":{"character":25,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src
REQ--> [textDocument/diagnostic] id=54  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 160ms [textDocument/completion] id=53  null
REQ--> [textDocument/documentHighlight] id=55  {"position":{"character":25,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Met
<--RSP 6ms [textDocument/documentHighlight] id=55  []
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"x","range":{"start":{"character":25,"line":40},"end":{"character":25,"line":40}},"rangeLength":0}],"textDocument":{"version":22,"uri":"file:
REQ--> [textDocument/completion] id=56  {"context":{"triggerKind":1},"position":{"character":26,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
REQ--> [textDocument/diagnostic] id=57  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 148ms [textDocument/completion] id=56  {"isIncomplete":true,"itemDefaults":{"data":{"TextDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler
NTF--> [textDocument/didChange] {"contentChanges":[{"text":" ","range":{"start":{"character":26,"line":40},"end":{"character":26,"line":40}},"rangeLength":0}],"textDocument":{"version":23,"uri":"file:
REQ--> [textDocument/completion] id=58  {"context":{"triggerCharacter":" ","triggerKind":2},"position":{"character":27,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src
REQ--> [textDocument/diagnostic] id=59  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 91ms [textDocument/completion] id=58  null
<--RSP 4103ms [textDocument/diagnostic] id=23  {"kind":"full","resultId":"PublicDocumentPullDiagnosticsHandler(category: ):1","items":[{"range":{"start":{"character":16,"line":268},"end":{"character":
REQ--> [textDocument/documentHighlight] id=60  {"position":{"character":27,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Portable\/Compiler\/Met
<--RSP 5ms [textDocument/documentHighlight] id=60  []
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"s","range":{"start":{"character":27,"line":40},"end":{"character":27,"line":40}},"rangeLength":0}],"textDocument":{"version":24,"uri":"file:
REQ--> [textDocument/completion] id=61  {"context":{"triggerKind":1},"position":{"character":28,"line":40},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/CSharp\/Po
REQ--> [textDocument/diagnostic] id=62  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"t","range":{"start":{"character":28,"line":40},"end":{"character":28,"line":40}},"rangeLength":0}],"textDocument":{"version":25,"uri":"file:
REQ--> [textDocument/diagnostic] id=63  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
<--RSP 234ms [textDocument/completion] id=61  null
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"r","range":{"start":{"character":29,"line":40},"end":{"character":29,"line":40}},"rangeLength":0}],"textDocument":{"version":26,"uri":"file:
REQ--> [textDocument/diagnostic] id=64  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"i","range":{"start":{"character":30,"line":40},"end":{"character":30,"line":40}},"rangeLength":0},{"text":"n","range":{"start":{"character":
REQ--> [textDocument/diagnostic] id=65  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
NTF--> [textDocument/didChange] {"contentChanges":[{"text":"g","range":{"start":{"character":32,"line":40},"end":{"character":32,"line":40}},"rangeLength":0},{"text":";","range":{"start":{"character":
REQ--> [textDocument/diagnostic] id=66  {"range":{"start":{"line":5,"character":0},"end":{"line":49,"character":0}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Compilers\/C
**RESPONSE TO FIRST DIAGNOSTIC AFTER 5s**<--RSP 5166ms [textDocument/diagnostic] id=26  {"kind":"full","resultId":"PublicDocumentPullDiagnosticsHandler(category: ):2","items":[{"range":{"start":{"character":16,"line":268},"end":{"character":

vscode
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"start":{"character":8,"line":44},"end":{"character":8,"line":44}},"rangeLength":0,"text":"p"}],"textDocument":{"uri":"file:\/\/\/Users\/mp
NTF--> [$/cancelRequest] {"id":94}
NTF--> [$/cancelRequest] {"id":95}
NTF--> [$/cancelRequest] {"id":96}
REQ--> [textDocument/diagnostic] id=97  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"identifier":"NonLocal"}
REQ--> [textDocument/diagnostic] id=98  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"previousResultId":"PublicDocum
REQ--> [textDocument/diagnostic] id=99  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"previousResultId":"PublicDocum
REQ--> [textDocument/diagnostic] id=100  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"previousResultId":"PublicDocu
REQ--> [textDocument/diagnostic] id=101  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"identifier":"XamlDiagnostics"
REQ--> [textDocument/diagnostic] id=102  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"previousResultId":"PublicDocu
REQ--> [textDocument/diagnostic] id=103  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"identifier":"HotReloadDiagnos
REQ--> [textDocument/diagnostic] id=104  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"previousResultId":"PublicDocu
REQ--> [textDocument/diagnostic] id=105  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"identifier":"WorkspaceDocumen
<--ERR [nil] id=94  {"message":"The task was cancelled.","code":-32800}
<--RSP 2ms [textDocument/diagnostic] id=97  null
<--ERR [nil] id=95  {"message":"The task was cancelled.","code":-32800}
<--RSP 0ms [textDocument/diagnostic] id=105  null
<--RSP 1ms [textDocument/diagnostic] id=101  null
<--RSP 1ms [textDocument/diagnostic] id=102  {"resultId":"PublicDocumentPullDiagnosticsHandler(category: enc):1","kind":"unchanged"}
<--RSP 1ms [textDocument/diagnostic] id=103  null
<--ERR [nil] id=96  {"message":"The task was cancelled.","code":-32800}
<--RSP 4ms [textDocument/diagnostic] id=104  {"resultId":"PublicDocumentPullDiagnosticsHandler(category: syntax):1","kind":"unchanged"}
<--RSP 7ms [textDocument/diagnostic] id=98  {"resultId":"PublicDocumentPullDiagnosticsHandler(category: DocumentAnalyzerSyntax):1","kind":"unchanged"}
<--RSP 5ms [textDocument/diagnostic] id=100  {"resultId":"PublicDocumentPullDiagnosticsHandler(category: DocumentCompilerSemantic):1","kind":"unchanged"}
<--RSP 7ms [textDocument/diagnostic] id=99  {"resultId":"PublicDocumentPullDiagnosticsHandler(category: DocumentAnalyzerSemantic):1","kind":"unchanged"}
REQ--> [textDocument/completion] id=106  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"},"position":{"character":9,"lin
REQ--> [textDocument/documentHighlight] id=107  {"position":{"character":9,"line":44},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamic
<--RSP 25ms [textDocument/documentHighlight] id=107  []
REQ--> [textDocument/_vs_getProjectContexts] id=108  {"_vs_textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/ExternalAccess\/Razor\/RazorDynamicFileInfo.cs"}}
REQ--> [textDocument/inlayHint] id=109  {"range":{"start":{"character":0,"line":0},"end":{"character":0,"line":57}},"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/roslyn\/src\/Tools\/Exter
<--RSP 2ms [textDocument/_vs_getProjectContexts] id=108  {"_vs_defaultIndex":0,"_vs_projectContexts":[{"_vs_id":"7a2dea60-2780-40c5-815b-3a8d3d9ada37|LspMiscellaneousFilesWorkspace Files Project for \
<--RSP 5ms [textDocument/inlayHint] id=109  []
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"start":{"character":9,"line":44},"end":{"character":9,"line":44}},"rangeLength":0,"text":"r"}],"textDocument":{"uri":"file:\/\/\/Users\/mp

There is already some work being done on pull diagnostics request only after the file is saved https://github.com/neovim/neovim/issues/29792.
But it seems that the problem here is really that the textDocument/diagnostic lacks additional information, as @mparq pointed out

yep, it seems the textDocument/diagnostic implementation in neovim does not support the previousResultId and identifier parameters that are in the lsp spec.

note to self
read more code of the current implementation of pull diagnostics in roslyn

Yeah okay, so it should probably be implemented in neovim then. I cannot guarantee that I myself will have time to do it, but I am not opposed to try and implement it if I find some time for it.
If anyone beats me to it, then great😄

I've implemented a change like this within function Client:_request(method, params, handler, bufnr):
  if last_result ~= nil then
    if last_result.resultId ~= nil then
      params.previousResultId = last_result.resultId
    end
  end

With this modification, the responses are significantly quicker. I haven't committed the change on a fork (for link the commit) because I'm not on Linux and am unable to build on Windows. This is a temporary fix.

So I am thinking about overriding the client request method and keeping the previous result id to see if that can make it better, but I don't know if I am just tired or something, but I was sure that this was going to work, and I cannot see what is wrong with this:
    config.on_attach = function(client, _)
        local req_inner = client.request

        function client:request(method, params, handler, req_bufnr)
            if method == "textDocument/diagnostic" and last_result ~= nil and last_result.resultId ~= nil then
                params.previousResultId = last_result.resultId
            end

            if handler then
                return req_inner(self, method, params, function(err, result, context)
                    last_result = result
                    return handler(err, result, context)
                end, req_bufnr)
            else
                return req_inner(self, method, params, handler, req_bufnr)
            end
        end
    end

If anyone can see what is wrong, then please give me a headsup😅 Maybe I am just tired or something

I made it work directly in the plugin. I'll open a PR after i check one more thing

Could someone who has a good reproduction of slowness test this: https://github.com/seblj/roslyn.nvim/pull/105
I was hoping it would sort of fix the lagging with diagnostics for me like here, but it seems to become faster with some time. That also seems to be the case without the fix though. I don't really have a good reproducible myself, but if this makes it faster for some of you we should of course do this
https://github.com/user-attachments/assets/adc4f394-0fdf-4eaf-bd0b-aa8fb86b2faa

@drzbida I gave your fix a try. Things do seem faster now thank you :) especially important for me is when editing for a while I'm not seeing the same behavior where nvim just freezes. That said, I do still see the diagnostic "backup" behavior, maybe that will need to be fixed using "identifier" in https://github.com/neovim/neovim/issues/31454. This is what I'm seeing in the traces now on the razor project.
because the full diagnostic pull for large projects still takes much longer to return than it takes to type, we get the issue where many in flight requests won't have previousResultId or will have an outdated one.
truncated trace (removed non diagnostic and didChange requests)
REQ--> [textDocument/diagnostic] id=16  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
REQ--> [textDocument/diagnostic] id=19  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":5,"line":27},"start":{"character":5,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=20  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":6,"line":27},"start":{"character":6,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=22  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":7,"line":27},"start":{"character":7,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=26  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":8,"line":27},"start":{"character":8,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=29  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":9,"line":27},"start":{"character":9,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=31  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
<--RSP 3444ms [textDocument/diagnostic] id=14  {"kind":"full","items":[],"resultId":"PublicDocumentPullDiagnosticsHandler(category: ):1
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":10,"line":27},"start":{"character":10,"line":27}},"text
REQ--> [textDocument/diagnostic] id=34  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):1","range":{"end":{"chara
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":11,"line":27},"start":{"character":11,"line":27}},"text
REQ--> [textDocument/diagnostic] id=37  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):1","range":{"end":{"chara
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":12,"line":27},"start":{"character":12,"line":27}},"text
REQ--> [textDocument/diagnostic] id=40  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):1","range":{"end":{"chara
<--RSP 1609ms [textDocument/diagnostic] id=16  {"kind":"full","items":[],"resultId":"PublicDocumentPullDiagnosticsHandler(category: ):2
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":13,"line":27},"start":{"character":13,"line":27}},"text
REQ--> [textDocument/diagnostic] id=42  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):2","range":{"end":{"chara

Could someone who has a good reproduction of slowness test this: #105
I was hoping it would sort of fix the lagging with diagnostics for me like here, but it seems to become faster with some time. That also seems to be the case without the fix though. I don't really have a good reproducible myself, but if this makes it faster for some of you we should of course do this
Screen.Recording.2024-12-05.at.22.08.38.mov

Wow, I never imagined it to be that slow. In any case, an issue should definitely be opened in neovim itself as these parameters are part of the 3.17 LSP spec and they are actually used in roslyn for some optimizations
Maybe it would be useful if you could try a Windows VM and opening your project to see if it behaves the same? (Unless someone here using Windows is having these issues). I've personally never seen this and we have a pretty big monorepo at my company. If it doesn't happen then it must be an issue with Roslyn (but that would mean you should see this issue in vscode too) or Neovim itself.
There could be another way it doesn't happen in vscode, Microsoft sometimes have modified versions of various tools in vscode. Although in all cases I know of they are clearly different in name, it takes 2 minutes to test using the dll from vscode, who knows..
You can find it here
C:\Users\bida.vscode\extensions\ms-dotnettools.csharp-2.55.29-win32-x64.roslyn\Microsoft.CodeAnalysis.LanguageServer.dll
For linux it's probably something like
~/.config/.vscode/extensions/ms-dotnettools.csharp-*/.roslyn/Microsoft.CodeAnalysis.LanguageServer.dll

@drzbida I gave your fix a try. Things do seem faster now thank you :) especially important for me is when editing for a while I'm not seeing the same behavior where nvim just freezes. That said, I do still see the diagnostic "backup" behavior, maybe that will need to be fixed using "identifier" in neovim/neovim#31454. This is what I'm seeing in the traces now on the razor project. (I've been using the file Compiler/Microsoft.CodeAnalysis.Razor.Compiler/src/Language/Legacy/CSharpCodeParser.cs to test as it has 3k+ lines)
because the full diagnostic pull for large projects still takes much longer to return than it takes to type, we get the issue where many in flight requests won't have previousResultId or will have an outdated one.
truncated trace (removed non diagnostic and didChange requests)
REQ--> [textDocument/diagnostic] id=16  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
REQ--> [textDocument/diagnostic] id=19  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":5,"line":27},"start":{"character":5,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=20  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":6,"line":27},"start":{"character":6,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=22  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":7,"line":27},"start":{"character":7,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=26  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":8,"line":27},"start":{"character":8,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=29  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":9,"line":27},"start":{"character":9,"line":27}},"text":
REQ--> [textDocument/diagnostic] id=31  {"textDocument":{"uri":"file:\/\/\/Users\/mparq\/code\/ext\/razor\/src\/Razor\/src\/Microsoft.A
<--RSP 3444ms [textDocument/diagnostic] id=14  {"kind":"full","items":[],"resultId":"PublicDocumentPullDiagnosticsHandler(category: ):1
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":10,"line":27},"start":{"character":10,"line":27}},"text
REQ--> [textDocument/diagnostic] id=34  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):1","range":{"end":{"chara
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":11,"line":27},"start":{"character":11,"line":27}},"text
REQ--> [textDocument/diagnostic] id=37  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):1","range":{"end":{"chara
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":12,"line":27},"start":{"character":12,"line":27}},"text
REQ--> [textDocument/diagnostic] id=40  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):1","range":{"end":{"chara
<--RSP 1609ms [textDocument/diagnostic] id=16  {"kind":"full","items":[],"resultId":"PublicDocumentPullDiagnosticsHandler(category: ):2
NTF--> [textDocument/didChange] {"contentChanges":[{"range":{"end":{"character":13,"line":27},"start":{"character":13,"line":27}},"text
REQ--> [textDocument/diagnostic] id=42  {"previousResultId":"PublicDocumentPullDiagnosticsHandler(category: ):2","range":{"end":{"chara

I'm not sure identifier will help in performance. I wrote more in the PR. Someone else also looking through the linked code would definitely help

Hmm, I can see if I can test this on linux and windows as well. That was tested on my mac, and that is also a very small project as well with around 50 files or something, and none of them over 200-300 lines long I think

I'm finally managing to reproduce in on some huge files.
Something very weird (imo) is that neovim sends a textDocument/diagnostic for every single character you've pressed after exiting normal mode. Default behavior is to update diagnostics on InsertLeave
• {update_in_insert}?  (`boolean`, default: `false`) Update diagnostics
                       in Insert mode (if `false`, diagnostics are
                       updated on |InsertLeave|)

I expected it to be done in a single request to be honest, but I guess keeping track of the changes is hard since you can also move with the arrow keys / etc ? It's definitely possible to do in a single request, after executing a command like :g/static/d requests diagnostics only once even though it deleted 217 lines for me. Could be worth exploring if an issue for something like this exists in neovim..
But then again, vscode updates on every keystroke too and works just fine, so there must be something else

Something very weird (imo) is that neovim sends a textDocument/diagnostic for every single character you've pressed after exiting insert mode

So it doesn't actually send it on TextChangedI/TextChangedP? But in vscode it does since that doesn't have a concept of different modes?
Do you notice any difference with/without the PR?

In my case (I found a 6k line test file) the changes from https://github.com/seblj/roslyn.nvim/pull/105 didn't make a significant difference, unfortunately
The vscode for the same change in the file needs ~5 seconds to display the diagnostics correctly.

Here are 2 screen recordings for comparison: from main branch and from PR
https://github.com/user-attachments/assets/5c44944d-29f5-46fd-8929-ebe58a85f84f
https://github.com/user-attachments/assets/13b11114-dd19-494e-a939-0b8eb1ec8156

So it doesn't actually send it on TextChangedI/TextChangedP? But in vscode it does since that doesn't have a concept of different modes?

No, I tested this and it seems like it sends the requests while I am typing

I tried to change it out to only update on InsertLeave by modifying neovim source code directly, and it seems significantly faster than the video I posted earlier in this thread...
It was a bit weird though, because it didn't clear the diagnostics again after undo and such since I only refreshed them on InsertLeave

My other thought is that it is an issue with inflight requests not being cancelled when they become outdated.
That would make the request feel snappier, if at the end of typing you didn't have to wait for all the outdated partially typed values to be computed.

Having a debounce for the diagnostics would help a lot. To me it seems like it's done in vscode too (at least with my config, where I don't remember changing anything like this)
I threw together a quick test hack for 0.10 only
local debounce_timer = nil

config.on_attach = function(client, attach_bufnr)
    local original_request = client.request
    local last_diagnostic = nil
    local pending_params = nil

    local function send_diagnostic_request()
        if pending_params then
            local params = pending_params
            pending_params = nil
            original_request("textDocument/diagnostic", params, function(err, result, ctx)
                print("actually sending diagnostic request")
                if result and result.resultId then
                    last_diagnostic = result
                end
                local handler = roslyn_config.config.handlers["textDocument/diagnostic"]
                    or vim.lsp.handlers["textDocument/diagnostic"]
                handler(err, result, ctx)
            end)
        end
    end

    client.request = function(method, params, handler, req_bufnr)
        if method ~= "textDocument/diagnostic" then
            return original_request(method, params, handler, req_bufnr)
        end

        params.previousResultId = last_diagnostic and last_diagnostic.resultId
        pending_params = params

        if debounce_timer then
            debounce_timer:stop()
        end

        debounce_timer = vim.defer_fn(send_diagnostic_request, 300)
    end

    if roslyn_config.config.on_attach then
        roslyn_config.config.on_attach(client, attach_bufnr)
    end
end

But i really am not sure why this is needed as this should work from my understanding with the debounce_text_changes flag in vim.lsp.client.flags
• {flags}                 (`table`) A table with flags for the client.
                          The current (experimental) flags are:
                          • {allow_incremental_sync}? (`boolean`,
                            default: `true`) Allow using incremental
                            sync for buffer edits
                          • {debounce_text_changes} (`integer`, default:
                            `150`) Debounce `didChange` notifications to
                            the server by the given number in
                            milliseconds. No debounce occurs if `nil`.
                          • {exit_timeout} (`integer|false`, default:
                            `false`) Milliseconds to wait for server to
                            exit cleanly after sending the "shutdown"
                            request before sending kill -15. If set to
                            false, nvim exits immediately after sending
                            the "shutdown" request to the server.

But it has no effect for me in roslyn. Is it possible it was not adapted for pull diagnostics?

To summarize, so far I see these problems which are not related to each other:

Diagnostics are requested in insert mode even with default settings when they are not shown (Neovim)
Debounce text changes has no effect for pull diagnostics ? (Neovim)
We don't send previousResultId for pull diagnostics

It's still slow, unclear how much it helped (maybe @molostovvs can also try with lsp references disabled) (Reason unknown)

I have tried a potential fix in neovim. Can one of you guys that can reproduce this try the PR?

For me it seems MUCH better just in this small file I have with under 100 lines of code. See the video I posted earlier for comparison
https://github.com/user-attachments/assets/9c1a6b17-3cac-4cd1-8b7b-8db817a1213c

same thing, it's much better, would be possible to do the same stuff in the plugin? thanks https://github.com/seblj/roslyn.nvim/pull/105 we have a wrapper for the request

I tried to cancell the request inside the plugin and the result was really good(2000 lines of code).
before:
https://github.com/user-attachments/assets/9658d023-91d7-4c7d-9bf2-9f5517845a3a
after:
https://github.com/user-attachments/assets/48d1a5e4-8368-4574-85c0-f99dcf4e3dd4
code that use https://github.com/seblj/roslyn.nvim/pull/105
	client.request = function(method, params, handler, req_bufnr)
				--delete request
				for rid, req in pairs(client.requests) do
					if req.method == method and req.type == 'pending' and req.bufnr == bufnr then
						client.cancel_request(rid)
					end
				end
				----
.....ecc

I don't know @seblj's thoughts but I think the best course of action is to get it fixed upstream and backported to 0.10.x

Yeah, I would prefer if we could get it merged and backported.
If it's not being backported, then I could be open to add a hack only for 0.10 since it's such a big improvement in performance.
However, I would like to wait with any hack until something is eventually merged into neovim

The range is because logic is shared within Neovims diagnostic and inlayhint refresh implementations
It isn't strictly correct, but it is what it is at the moment.
There is also no central LSP datastore to hold the identifier information, so as a workaround for "one shot" diagnostics which is all that Neovim supports at the moment. Then it seems the best workaround.
It might be good for you to create an issue in neovim/neovim for that range being included as that is something that can be corrected

Okay, it was merged in neovim now, and a backport seems to be in progress

Just piling on here, just got around to testing. Things are way faster now! Thanks @tris203. I'm also seeing that with the cancelRequest changes, the lsp textDocumemt/diagnostic responses from the language server consistently return in ~150-250ms for me, whereas before the changes they could take up to 5000ms which I'm now thinking was scaling based on how fast I was typing. Still not the ~5ms responses from vscode diagnostic requests which include identifier field but so much better than it was

I'm not sure about 10.2, but the lagging experience broke my workflow so after the fix I switched to 11 and since then I have no issues with lag anymore.

Not working of me yet on 10.2, but updating to 11 does siiiiiignificantly improve it.

I guess you need to reinstall 0.10.2 to notice any improvements

I'm guessing the problem was originated from either neovim itself or roslyn. Just updated my neovim to latest commit and upgraded roslyn to latest version from Mason.
Diagnostics are WAAAAAAAY faster now.


Fix the creation of all metrics-server resources.

Codecov Report

Merging #1036 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1036   +/-   ##
=======================================
  Coverage   34.92%   34.92%
=======================================
  Files          59       59
  Lines        4160     4160
=======================================
  Hits         1453     1453
  Misses       2545     2545
  Partials      162      162

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b9a7cf...7ec0adb. Read the comment docs.


Moving bar due to text

Describe the issue
A clear and concise description of what the bug is.
Whenever a module has "dynamic" text (i.e: Changing, like the system clock, or internet speed), it moves left and right.
I tried changing the fonts I use, used the default ones, but nothing worked. Obviously it might still be a font problem, I haven't tried them all...
Expected behavior:
The bar should stay static regardless of the output.
Actual behavior:
Well, if my upload speed is 200KB/s for instance, the remaining text on the bar will move a bit to the left to accommodate for the additional characters.
To Reproduce
A minimal but complete config with which the problem occurs:
[colors]
background = #222
background-alt = #444
foreground = #dfdfdf
foreground-alt = #555
primary = #ffb52a
secondary = #e60053
alert = #bd2c40

[bar/mybar]
monitor = ${env:MONITOR:}
width = 100%
height = 20
radius = 0.0
fixed-center = false
bottom = true
background = ${colors.background}
foreground = ${colors.foreground}
line-size = 2
line-color = #f00
border-size = 0
border-color = #00000000
padding-left = 2
padding-right = 2
module-margin-left = 2
module-margin-right = 2
font-0 = Cantarell:pixelsize=10;1
font-1 = fixed:pixelsize=10;1
font-2 = unifont:fontformat=truetype:size=8:antialias=false;0
font-3 = Wuncon Siji:pixelsize=10;1
modules-left = i3 mpd
modules-right = root home internal memory cpu temperature internet vpn date
tray-position = right
tray-padding = 3
scroll-up = i3wm-wsnext
scroll-down = i3wm-wsprev
cursor-click = pointer
cursor-scroll = ns-resize
separator = |

[module/i3]
type = internal/i3
pin-workspaces = true
strip-wsnumbers = false
index-sort = false
enable-click = false
enable-scroll = true
wrapping-scroll = false
reverse-scroll = true
format = <label-state> <label-mode>
label-mode = %mode%
label-mode-padding = 2
label-mode-background = #e60053
label-focused = %name%
label-focused-foreground = #ffffff
label-focused-background = #3f3f3f
label-focused-underline = #fba922
label-focused-padding = 2
label-unfocused = %name%
label-unfocused-padding = 2
label-visible = %index%
label-visible-underline = #555555
label-visible-padding = 2
label-urgent = %name%
label-urgent-foreground = #000000
label-urgent-background = #bd2c40
label-urgent-padding = 2
label-separator-padding = 2
label-separator-foreground = #ffb52a

[module/root]
type = internal/fs
mount-0 = /
interval = 1
format-mounted = <label-mounted>
label-mounted = %{F#28bed8}Root:%{F#FFFFFF}  %free%

[module/home]
type = internal/fs
mount-0 = /home
interval = 1
format-mounted = <label-mounted>
label-mounted = %{F#28bed8}Home:%{F#FFFFFF}  %free%

[module/games]
type = internal/fs
mount-0 = /home/henry/games
interval = 1
fixed-values = true
format-mounted = <label-mounted>
label-mounted = %{F#28bed8}Games:%{F#FFFFFF}  %free%

[module/mpd]
type = internal/mpd
format-online = <label-song> - <label-time>
label-song = %artist% - %title%
label-song-maxlen = 64
label-song-ellipsis = true

[module/cpu]
type = internal/cpu
interval = 1
format = "<label>%"
format-prefix = " CPU: "
format-prefix-foreground = #4bffdc
label = %percentage%

[module/temperature]
type = internal/temperature
thermal-zone = 0
warn-temperature = 60
hwmon-path = /home/henry/.config/polybar/hwmon/temp1_input
format = <label>
format-prefix = " TMP: "
format-prefix-foreground = #4bffdc
format-warn = <label-warn>
format-warn-prefix = " TMP: "
format-warn-prefix-foreground = #ff0000
label = %temperature-c%
label-warn = %temperature-c%
label-warn-foreground = #ff0000

[module/memory]
type = internal/memory
interval = 1
format-prefix = " RAM: "
format-prefix-foreground = #4bffdc
label = %gb_used%

[module/internet]
type = internal/network
interface = enp2s0
interval = 1
label-connected = " E: %local_ip% ( D: %downspeed% | U: %upspeed% )"
label-connected-foreground = #55aa55
udspeed-minwidth = 3
label-disconnected = "  E: Offline"
label-disconnected-foreground = #ff0000

[module/vpn]
type = internal/network
interface = tun0
interval = 1
label-connected-foreground = #55aa55
label-connected = " VPN: On"
label-disconnected = " VPN: Off "
label-disconnected-foreground = #ff0000

[module/date]
type = internal/date
interval = 1
label = %time% %date%
date = "%A  %d/%m/%y"
time = " %H:%M -"
format-prefix = 
format-prefix-foreground = #0a6cf5

[settings]
screenchange-reload = true
;compositing-background = xor
;compositing-background = screen
;compositing-foreground = source
;compositing-border = over

[global/wm]
margin-top = 5
margin-bottom = 5
; vim:ft=dosini

List any other steps needed to reproduce the issue besides starting polybar with the config you posted above.
Not much really, download something, make your CPU heat up or whatever, the numbers need to change. On the other hand, you could just add %s to the time in my date module, since it also happens when the clock changes.
Environment:

WM: i3
Output of `polybar -vvv:

Features: +alsa +curl +i3 +mpd +network(libnl) +pulseaudio +xkeyboard
X extensions: +randr (+monitors) -render -damage -sync +composite +xkb +xrm +xcursor

Build type: RelWithDebInfo
Compiler: /usr/bin/c++
Compiler flags: -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Wall -Wextra -Werror -Wno-noexcept-type -pedantic -pedantic-errors
Linker flags: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now

Additional context
Issue is similar to #82 but affects pretty much any text that changes (Clock, CPU usage and temp, download speed, etc)
I tried doing what was recommended here with no success.

If you actually want modules with static width, you need to make sure that no token that you use can ever change its width. You can do that by having their max and minwidth properties to the same value, this way they always stay the same width.
You also need to make sure that your fonts are all monospaced because the max and minwidth values are all measured in spaces and having a non-monospaced font can have the same number of characters take a different amount of space. I'm pretty sure Cantarell is not monospaced, use something like DejaVu Sans Mono or Noto Sans Mono

@patrick96 This might be a different problem then, but I'm having the same issue. I am using a monospaced font (Inconsolata):
[module/pulseaudio]
type = internal/pulseaudio
use-ui-max = false
format-volume =
label-volume = VOL %percentage:3:3%
label-muted = MUTE %percentage%
label-muted-foreground = #666
When changing the volume so the number of digits in its values change (e.g. 0 to 50 and then to 100), it shifts all the modules to the left (this pulseaudio module is defined at module-right). I've tried setting the max/minwidth to 2, 3, and 4. Obviously setting it to 1 would not cause any shifting, but is not useful at all.

I'm having the same issue. I'm using a monospaced font and I set the max and min width to the same value.

@lopezdylan If you think this is an issue with your config and want help fixing it, please ask on Gitter or one of our other support sites. If you think this is a bug in polybar, please open a new issue.

This also doesn't work for me unless I 0 pad the number. It doesn't seem to respect min width without a pad value.

@danjenson Tokens are space padded by default. But if you use a non-monospaced font spaces take less space than a regular character would and so you have shifting. First make sure you didn't accidentally use a non-monospaced font.
Even if you meant to use a monospaced font, it's possible that polybar failed to load it


remove miq_group v4 data migration

Since #4204 sets the tenant, MiqGroup.seed does not need to set MiqGroup#tenant.
Since we no longer support migrating a v4.0 database, MiqGroup.seed does not need to migrate pre 4.0 MiqGroup#miq_user_role values.

/cc @gmcculloug this is what we discussed

@gtanzillo @Fryguy Please review

I remember leaving this in when I recently removed UiTask because I don't believe there is a migration that fixes it.  @gmcculloug was helping me out with that, so if he agrees it can come out, I am good with it. (I really want it removed too)

Since we no longer support migrating a v4.0 database

Sort of.  We can only truly no longer support it if there's an actual migration for a previous version.

@Fryguy you would prefer: #4255 ?

chose 4255 instead


Remove loggerfactory from testbase

Removed the obsolete loggerfactory from testbase and update all unit tests using it to use the mock instead.
See https://github.com/stratisproject/StratisBitcoinFullNode/issues/1299

Hey @Neurosploit can you fix the conflicts? Cheers.

I've done the merge as it conflicted with my previous changes. Let's see if it builds!

No, that didn't work. @Neurosploit can I leave it to you?


Documentation updates

Fixed minor confusions in documentation about instance sizes for AML and also AML Dataset configuration in Models

All good.

All good.


refactor(egen) : refactored notebook according to template guidelines nd added missed modules and libraries

This PR includes
1.replaced variable REGION to LOCATION
2.imported required modules
3.added missed libraries in installation section
4.added colab enterprise link
5.added Colab authentication and kernal restart steps.
6.refactored notebook according to template guidelines
REQUIRED: Fill out the below checklists or remove if irrelevant

If you are opening a PR for Official Notebooks under the notebooks/official folder, follow this mandatory checklist:

[x] Use the notebook template as a starting point.
[x] Follow the style and grammar rules outlined in the above notebook template.
[x] Verify the notebook runs successfully in Colab since the automated tests cannot guarantee this even when it passes.
[x] Passes all the required automated checks. You can locally test for formatting and linting with these instructions.
[ ] You have consulted with a tech writer to see if tech writer review is necessary. If so, the notebook has been reviewed by a tech writer, and they have approved it.
[ ] This notebook has been added to the CODEOWNERS file under the Official Notebooks section, pointing to the author or the author's team.
[x] The Jupyter notebook cleans up any artifacts it has created (datasets, ML models, endpoints, etc) so as not to eat up unnecessary resources.

some edits. Wondering why this one was updated since it references: https://cloud.google.com/vertex-ai/docs/training-overview#text_data, which is being deprecated

mistake, replaced with original reference : https://cloud.google.com/vertex-ai/docs/datasets/prepare-text#sentiment-analysis

/gcbrun


Update to 1.18 :)

I dont know if you're planning to update or not , but I just want to make sure that you will , because this mod is very cool and is what i exactly need .

I do want to update this mod to 1.18 at some point, but my time is quite limited. I have no ETA for updating it.


restaurant demo example don't work

Rasa Core version: latest version 0.11.8
Python version: 3.6
Operating system (windows, osx, ...):Centos Aws
Issue: restaurant example don't work
Content of domain file (if used & relevant):

Please post the command you used that caused this error

I ran into the same error. I train both nlu and core successfully, but when using the agent to load the pretrained core model, I got the following error message:
File "/home/*/miniconda3/envs/rasa_chatbot_0.11/lib/python3.6/site-packages/tensorflow-1.11.0-py3.6-linux-x86_64.egg/tensorflow/python/keras/engine/saving.py", line 251, in load_model
    training_config['weighted_metrics'])
KeyError: 'weighted_metrics'

@jonDel I don't remember how I solve this problem. But I do know it is something related to tensorflow version.

@jonDel  hey I met this problem again.
Now I found the problem.
When you do pip3 install -r requirements it will have this problem
Try to do pip install -r requirements to see if it works.
It works for me.

Ok so the problem is probably that you trained your model with tensorflow==0.10 but then loaded the model with tensorflow==0.11, we're gonna merge a fix asap

@akelad , my custom model was using pure keras instead of the recently added keras module from tensorflow. It seems that the whole issue is related to a namespace confusion. I changed my custom model to use tensorfow.keras and all went well.


[Bug] Copy-DbaDatabase | Conversion failed

Environmental information
Run below command, paste results below:
PowerShell version:
PSVersion                      5.1.14393.2969
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.2969
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
dbatools Module version:
Name    : dbatools
Path    : C:\Users\user\Documents\WindowsPowerShell\Modules\dbatools\0.9.834\dbatools.psd1
Version : 0.9.834
SQL Server:
Microsoft SQL Server 2012 (SP4-GDR) (KB4057116) - 11.0.7462.6 (X64)   Jan  5 2018 22:11:56   Copyright (c) Microsoft Corporation  Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.3  (Build 9600: ) (Hypervisor)

### Report

Not able to use Copy-DbaDatabase with backup/restore method. Failing with "Verify service account access" and "Conversion failed when converting date and/or time from character string". I have confirmed service account permissions so there is not problem there. I get the same error if I use Backup-DbaDatabase

#### Errors Received

writeErrorStream      : True
PSMessageDetails      :
Exception             : System.Exception: Conversion failed when converting date and/or time from character string. ---
                        > System.Data.SqlClient.SqlException: Conversion failed when converting date and/or time from c
                        haracter string.
                           at Microsoft.SqlServer.Management.Common.ConnectionManager.ExecuteTSql(ExecuteTSqlAction act
                        ion, Object execObject, DataSet fillDataSet, Boolean catchException)
                           at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteWithResults(String sqlComma
                        nd, Boolean retry)
                           --- End of inner exception stack trace ---
TargetObject          :
CategoryInfo          : NotSpecified: (:) [Write-Error], Exception
FullyQualifiedErrorId : dbatools_Backup-DbaDatabase,Stop-Function
ErrorDetails          : Conversion failed when converting date and/or time from character string.
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at Stop-Function, C:\Users\user\Documents\WindowsPowerShell\Modules\dbatools\0.9.831\al
                        lcommands.ps1: line 110290
                        at Backup-DbaDatabase<Process>, C:\Users\user\Documents\WindowsPowerShell\Modules\dbato
                        ols\0.9.831\allcommands.ps1: line 2946
                        at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}

#### Steps to Reproduce

1. Create share with source and destination service account with full control permissions
2. Run Backup-DbaDatabase or Copy-DbaDatabase on SQL2012,SQL2016,SQL2017 instance with norwegian/danish locale.

#### Expected Behavior

Backup and restore complete without errors

#### Actual Behavior

Backup fails with Conversion failed when converting date and/or time from character string

awesome, thank you for the complete report! we have a fix coming in for this today.

can you please confirm that the engine has the alternative locale? does powershell have an alterantive locale as well?

Thanks, should be fixed now! the fix will be released with dbatools 1.0 on Thursday morning 💯

Is it possible to get the CheckSum and VerifyOnly added to the copy-dbadatabase for the backup/restore option?


All headers missing from generated contract test when using absent() for one of them

I'm using Spring Cloud Contract 2.2.6.RELEASE.
I've written a contract that uses absent() for one of the headers:
Contract.make {
    request {
        method 'POST'
        urlPath '/foobar'
        headers {
            header(authorization(), absent())
            contentType(MediaType.APPLICATION_JSON_VALUE)
        }
        body([...])
    }
    response {
        status FORBIDDEN()
    }
}

I'm expecting the generated test to contain the Content-Type header, but there are no headers at all:
RequestSpecification request = given()
		.body(...);

When I switch the order of the headers, then the generated test does include the Content-Type header:
Contract.make {
    request {
        method 'POST'
        urlPath '/foobar'
        headers {
            contentType(MediaType.APPLICATION_JSON_VALUE)
            header(authorization(), absent())
        }
        body([...])
    }
    response {
        status FORBIDDEN()
    }
}

RequestSpecification request = given()
		.header("Content-Type", "application/json")
		.body(...);

Based on my investigation, this is caused by the return statement in this bit of code from org.springframework.cloud.contract.verifier.builder.MockMvcHeadersGiven:
private void processInput(BlockBuilder bb, Headers headers) {
	Iterator<Header> iterator = headers.getEntries().iterator();
	while (iterator.hasNext()) {
		Header header = iterator.next();
		if (ofAbsentType(header)) {
			return;
		}
		if (iterator.hasNext()) {
			bb.addLine(string(header));
		}
		else {
			bb.addIndented(string(header));
		}
	}
}

Hi @cselagea , thank you for the analysis. Are you willing to file a PR with a test and a fix?

Sure, I'll give it a go, @marcingrzejszczak


Ranks will not appear on every server

I have recently switched to using LuckPerms for my minecraft server, but have realised that the ranks don't appear on all of the servers (I'm using Bungeecord). How can I fix this? I have entered the mysql database on all of the servers and changed the storage type to mysql.

Please ensure you have IP-Forwarding setup correctly on ever server. This means you must have ip-forwarding set to true in your bungeecord config, and have bungeecord set to true in your spigot.yml.

@iSpoopy You must set messaging-service to bungee in both servers and BungeeCord LuckPerms config file. And your network must be setup as @merjilin said.

https://github.com/lucko/LuckPerms/wiki/Network-Installation


Add getErrorType to InstagramException

It would be nice if we could get a getErrorType() on InstagramException, now it concatenates error_type and message into one string and sets this as the error message of the exception, this makes is hard to react properly on the different kinds of errors (error_type).

Added in the current bulld


Fix flaky testDeletePartition by sending to specific partitions

Fixes #1161
Motivation
The testDeletePartition relies on the fact that h has been sent to partition 1. However, Kafka's default partition assignor cannot guarantee that. See example debug logs:
KafkaProducer send 'g' to test-delete-partition-partition-1@3
KafkaProducer send 'h' to test-delete-partition-partition-0@3
KafkaProducer send 'i' to test-delete-partition-partition-1@3

These three messages (g, h, i) were sent in a round robin way. However, h was sent to partition 0 while g and i were sent to partition 1, which was deleted later. Then the Kafka consumer can only receive 1 message and receiveMessages will be stuck because the expected number of messages is 2.
Modifications
Send g, h, i to the specific partitions directly using the following overload of ProducerRecord:
ProducerRecord(String topic, Integer partition, K key, V value);

Documentation

[ ] doc-required
[x] no-need-doc
[ ] doc

I've applied the following patch and the tests all passed.
diff --git a/tests/src/test/java/io/streamnative/pulsar/handlers/kop/BasicEndToEndKafkaTest.java b/tests/src/test/java/io/streamnative/pulsar/handlers/kop/BasicEndToEndKafkaTest.java
index 943c3243..7a93bc3f 100644
--- a/tests/src/test/java/io/streamnative/pulsar/handlers/kop/BasicEndToEndKafkaTest.java
+++ b/tests/src/test/java/io/streamnative/pulsar/handlers/kop/BasicEndToEndKafkaTest.java
@@ -26,6 +26,7 @@ import java.util.Collections;
 import java.util.List;
 import java.util.concurrent.CountDownLatch;
 import java.util.concurrent.Future;
+import java.util.concurrent.atomic.AtomicInteger;
 import java.util.stream.Collectors;
 import java.util.stream.IntStream;
 import lombok.Cleanup;
@@ -402,9 +403,11 @@ public class BasicEndToEndKafkaTest extends BasicEndToEndTestBase {
         }
     }

-    @Test(timeOut = 20000)
+    private static final AtomicInteger TEST_ID = new AtomicInteger(0);
+
+    @Test(timeOut = 20000, invocationCount = 10)
     public void testDeletePartition() throws Exception {
-        final String topic = "test-delete-partition";
+        final String topic = "test-delete-partition" + TEST_ID.getAndIncrement();

         pulsar.getAdminClient().topics().createPartitionedTopic(topic, 2);


Wraptable fix

added 3 backticks to close table format. Now the tables are functional with the chatGPT code. Will continue later.


GCA Export: Equipment with Modified Weight Retains Unmodified Weight when Imported

In GCA, equipment that has a modifier that changes the weight of an item retains the unmodified "baseweight" in the .gca4 file, but also has a modified "weight" that is displayed to the user.
So, we end up with something like this in GCA:

(Unmodified; weight x0.70; weight x0.25)
When I export that, I get both original "weight" (GCA "baseweight") and "weightsum" (GCA modified "weight") in the export file.
However, when I import into Foundry, I get this:

It looks like the import is ignoring the "weightsum" because there are only one of each of the items—if I add a second one of either of the modified breastplates in GCA and import again, it then starts displaying the "weightsum" as the "weight":

Here's a .zip with the GCA character file and the export:
EquipModWeightChar.zip
If it helps, the Masterful Tailoring modifier is from the Low-Tech GCA data file, and the SM -2 modifier is from the Low-Tech Companion 2 - Weapons and Warriors data file.

Fixed in next release


[North Star Applicant UI]: Add support for modal dialogs

Describe the solution presented in this issue.
Load any modal dialogs needed on load in applicant pages. Update the data-load-modal attribute on the body appropriately for screenshot tests
Done when:
What criteria need to be met for the issue to be finished?

[ ] All modal dialogs in the applicant UI flow are shown, and data-load-modal is removed without breaking any screenshot tests.

Individual issues will be filed for individual modal dialogs to be added

I think that is going to be a question of scoping for product, which is still in progress. This issue in particular is just tied to including modals in the html we render, rather than the content of the modals themselves.
The modals you link to fall into 3 buckets:

showed in page for applicants (just the login modal)
modals shown in their own page for applicants
modals not shown to applicants.

3 will definitely be out of scope, 1 and 2 are still TBD whether they are going to be updated, but I will file issues for individual modals when the scoping is finalized

I request that we wrap the modal in the <dialog> element. We don't have to use the dialog api, I just want the semantic markup.

We have support for modals now, so i'm going to close this out, and file issues for individual modals that need to be implemented


[Request for External] Page "Whse. Receipt Subform" - global variable "CrossDockOpp2"

Page "Whse. Receipt Subform"
please make the global variable "CrossDockOpp2" accessible.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


refs #1502 - make custom twill blade directives translatable

Description
this PR enables translations for blade directives like @twillRepeaterTitle
Related Issues
Addresses #1502

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Fabian Polkehn seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you for your contribution @cpfpolkehn.
While this for sure solves the issue, I am not sure it is the solution that we should take.
I feel it might be better to have the translatable string in the property something like:
@twillRepeaterTitle(__('Category'))
@twillRepeaterTrigger(__('Add cat'))

But this does not work yet at the moment.
What are your thoughts @ifox?

@haringsrob Hello, I think in your example it should rather be @twillRepeaterTitle(twillTrans('Category')) than @twillRepeaterTitle(__('Category')) because __ would ignore the Twill user's language.

Closing this as we refactor to use __ in https://github.com/area17/twill/pull/1523


Have you seen this Bluetooth solution?

I was wondering have you seen this?
https://github.com/Olen/solar-monitor
I don’t know enough programming to work out but could this be combined with your integration?

A bit late, but i started a new integration based on bluetooth: https://github.com/ElD4n1/home-assistant-renogy-rover-bluetooth-integration


doc(readme): add chat badge

Add a badge that links to the olm-dev channel in the Kubernetes Slack instance.

Side note: we shouldn't be running any CI on changes made to the root README.md :shrug:
/lgtm


Make g.calibrate code more robust to long nonwear periods

See issue https://groups.google.com/g/RpackageGGIR/c/5eed6aIJa7Q/m/9pXLSIUqAgAJ?utm_medium=email&utm_source=footer
To do: Make g.calibrate code more robust to missing values or many zeros.

closing this now, because I this has been improved in recent PRs


When creating a new question, the minimum 6 -character limit is invalid, and it can still be successfully created.

When creating a new question, the minimum 6 -character limit is invalid, and it can still be successfully created.

Fixed, please upgrade to v1.0.1


Add files via upload

New school from Ukraine

@KlimEnN First stage of verification passed, official domain is gymnasia-npu.org.ua as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@KlimEnN Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Fix import error in certain environment

Fixes #4, #9
"type":  "module" might also be desirable to indicate that the code is using ESM, and I do have it in my local patch working fine, but not sure if this would interfere with the build process of the package so didn't include it.

Thanks, bro. Let's have a try!
Version v1.0.9-alpha.2 has been released :)


Add Service Monitor

Signed-off-by: Salvatore Mazzarino<EMAIL_ADDRESS>This PR adds the Service Monitor useful when Traefik is deployed in a cluster where Prometheus Operator is deployed.
Prometheus metrics flags have been added to Traefik command.
The approach follows the one from the stable Helm chart.

I add to rename from service.yaml to service-prometheus.yaml the file because was colliding under unit test with the service.yaml in the parent dir.
Wondering if there is a better way to handling this naming collision.

There is an opened issue in the upstream repo https://github.com/lrills/helm-unittest/issues/44
At the current stage seems not possible to have subdirs having files with the sane name.

I'm going to add some unit tests later today.

Hello,
could you test locally?
FYI we receive a mail for each commits.

@ldez Sure. I will. Sorry for spamming here.

Unit tests green here. Ready for review.

@mazzy89
Is it possible to enable this feautre by a CLI parameter to helm install?

Traefik flags are defined . Service monitor is not a feature of Traefik but it is a CR belonging to prometheus operator

@ldez do you see here any blockers?

Hi @mazzy89,
Thanks for your contribution.
We should probably only enable Prometheus in this PR and keep the ServiceMonitor outside of the helm chart.
Because adding option like that will increase the complexity of the helm chart. And I think we should keep the helm chart as simple as possible. This option is specific to people that have Prometheus Operator installed and want to use ServiceMonitor. So we will probable have other people that would want to have PodMonitor and maybe other people that would like to use annotation to scrape metrics.
So we should keep thing most generic as possible and as simple as possible.
So could you please remove the service monitor part and only keep the prometheus configuration?

I see. No problem. I'm going to remove ServiceMonitor.

Thanks
FYI I worked on an example available here https://github.com/mmatur/prometheus-traefik

@mazzy89
Metrics on traefik can be enable with the following values.yaml:
additionalArguments:
  - "--metrics.prometheus=true"
  - "--entryPoints.metrics.address=:9100"
  - "--metrics.prometheus.entryPoint=metrics"

For this reason I will close your PR.
Thanks a lot for your contribution

True but it would have been nice to put the configuration in the values.yaml rather than to play with flags that can be more error prone. But as you say

It's very strange decision not to include a feature flag with ServiceMonitor. There is no convenient and simple way to add custom templates to existing charts, so you just kill the value of this chart when decline this widely used feature.

@n4nn31355 thanks for this. I completely agree with you. The maintainer here claims to keep the helm chart simple without including it but I really have hard time to get how including such CR like service monitor can increase complexity. We are talking here of a bunch of YAML manifests baked even by unit tests.  I would agree if there was some lesson learned with the helm chart for traefik 1.x but I don't think there is here, that helm chart is there for pretty long time and it is is stable and more important not hard at all.

@mazzy89 @n4nn31355 They are just sticking with the "if its k8s native or traefik native it can be added, otherwise it has conflicts of interest". That said if you add the incubator/raw chart as a subchart you can accomplish adding a servicemonitor extremely simply!


Update products

Looks like the products list have gotten updated so we cannot submit radars for some types until this list is updated

How's the product list normally updated? Manually by hand?

Ah, I see: https://bugreport.apple.com/developerUI/problem/getProductAreaList


Updating api-webapp with API keys for apps

Setting the API keys for official OBA Apps.  Fixes #2.

Sorry I missed the notification about this PR!
Thank you for this.


Saving tabs and queries to disk by server & automatically reloading on server selection

In regards to issue #318
Currently in progress but looking for feedback -- Mostly done, just need to thoroughly test it. Finished
I'm persisting store.queries by serverId in the sqlectron.json file on every action that updates queries, debounced by 500ms.
When selecting a server, upon successful connection I'm retrieving the stored data and dispatching an action to put it in the store if a stored query list exists.
Right now I have an odd bug in that if your last selected tab was any besides the first, and you log out then back in and select tab 1, it won't pop in the text for tab 1 until you click the editor pane. I don't know why, but if I can't figure that out.
I think I'm going to just default to tab 1 on every load, because if tab 1 is the initial tab it works fine. Fixed it -- See below
In this PR I also made the selectedQuery value get passed into the actions -- my initial plan for implementation was going to have me updating only changed parts, but decided it was easier to just store an entire snapshot of the queries object from the store.
During this PR I somehow introduced a bug in the REMOVE_QUERY reducer, at the line where the removed query was being deleted from the queriesById object. I fixed that by bringing in lodash.omit and just omitting that key instead.
My thought here is that this was failing due to mutating the underlying data, as simply spreading state to make a copy only made a shallow 1-layer deep copy, so the delete command was trying to directly mutate data in the store (because queries.queriesById is only a pointer at this point, not a copied value) -- _.omit() returns a brand new object without mutating, and this is generally regarded as best practice.
Here's an example of a sqlectron.json file after this PR w/ 2 tabs open in my second db (note: these are the docker instances, so passwords aren't secure)
  "servers": [
    {
      "id": "14455516-25b2-40f4-879a-02df23f8c168",
      "name": "docker-pg",
      "client": "postgresql",
      "ssl": false,
      "host": "<IP_ADDRESS>",
      "port": 5432,
      "socketPath": null,
      "user": "user",
      "password": "14488c2275e8fd79",
      "database": "company",
      "schema": null,
      "encrypted": true
    },
    {
      "id": "fe61b1a7-f815-4c26-95c4-bb628c67a606",
      "name": "docker-mysql",
      "client": "mysql",
      "ssl": false,
      "host": "<IP_ADDRESS>",
      "port": 3306,
      "socketPath": null,
      "user": "root",
      "password": "14488c2275e8fd79",
      "database": "authentication",
      "schema": null,
      "encrypted": true
    }
  ],
  "queries": {
    "fe61b1a7-f815-4c26-95c4-bb628c67a606": {
      "lastCreatedId": 3,
      "currentQueryId": 2,
      "queryIds": [
        1,
        2
      ],
      "queriesById": {
        "1": {
          "id": 1,
          "database": "authentication",
          "name": "authentication #1",
          "filename": null,
          "isExecuting": false,
          "isDefaultSelect": false,
          "didInvalidate": true,
          "query": "query 1",
          "selectedQuery": 1,
          "queryHistory": [],
          "results": null,
          "error": null,
          "copied": false,
          "resultItemsPerPage": 100
        },
        "2": {
          "id": 2,
          "database": "authentication",
          "name": "authentication #2",
          "filename": null,
          "isExecuting": false,
          "isDefaultSelect": false,
          "didInvalidate": true,
          "query": "query 2",
          "selectedQuery": 2,
          "queryHistory": [],
          "results": null,
          "error": null,
          "copied": false,
          "resultItemsPerPage": 100
        }
      },
      "resultItemsPerPage": 100,
      "enabledAutoComplete": true,
      "enabledLiveAutoComplete": true
    }
  }
}```

Fixed that bug I was seeing w/ the tabs -- connection success spawns a new tab, but then it was being overridden right after by setting the cached state and a re-render just wasn't happening -- so I just tied in to the CONNECTION_SUCCESS action for setting the initial state -- it's either a call to addNewQuery or it's the result of spreading initial state w/ the stored values.

How do you feel about storing the result of the queries to disk?
My thought was that would cause the JSON to get potentially way too massive and for someone who uses a lot of tabs would cause pretty long load times when starting the app, especially if they had a couple SELECT * queries open on large databases.

Yeah, I think that could lead to performance issues pretty easy. I don't think is necessary to save the results. With the restored queries, the user should be able to execute it again with no problem.

@s-kem This week I'm quite busy. I will review/merge it up to Friday though.

@maxcnunes No problem! Thanks for letting me know.

I did break it but it wasn't that this.refs.queryBoxTextArea.editor.on() function that did it.
I was confused as to what selectedQuery was supposed to be within each queryById object, I thought it was supposed to be the currently selected query tab, and didn't notice it's inside each query object.
I thought it was just not being used to in all cases to pass back the current tab ID, so I made changes to make sure it did. The cmd+enter keyboard shortcut was relying on a different value that was now the query ID.
I should have undid those changes to start with because they weren't even necessary for the implementation I ended up going with, so I reverted.
I also caught that I wasn't correctly clearing errors/previous results, so I brought in mapValues from lodash in order to map over each queriesById object and set the result to an empty array and error to null.

Hey @s-kem, I took some time to review it today. The code looks good. But I have found few bugs 😢
Related to queries stored state:

The "Select rows" from the sidebar context menu does not trigger the action to save the query. I have not tested the other context menu options. But believe they probably don't work too.
The restoring state from a database connection that is not the initial one fails.

Related to the "execute selected text"
Seems it is not working anymore. Looks like it is always executing the whole query box content. Here are GIFs showing the before and after:
Before your changes

After your changes

Ooohhh, man, I feel so dumb for that. I get why that dispatch was happening now. Also, I didn't even know that was a feature of this app, so that's awesome!
In hindsight I would've introduced some unwanted behaviour in saving the state had I not done that. I'm also clearing selectedQuery from each query prior to writing to disk.
Ive reverted removing that code... It wasn't causing an error anymore in my implementation...
in fact I just squashed all the commits down into one so the history doesn't get messy. Should be fine since nothing else was based on this work yet.
Thanks for your patience in helping me get through it.
Is there any other data you can think of we shouldn't be saving to disk? I was considering clearing queryHistory so it doesn't balloon up over time... or at least pruning it to say the last 10.

No worries, you have been doing a great work so far :)
By this quote below, did you mean it will not include the context menu queries?

In hindsight I would've introduced some unwanted behaviour in saving the state had I not done that.

I believe on MySQL Workbench it restores all tabs, even the empty ones. I think that is a more expected behaviour at least.
queryHistory was supposed to be used for this feature https://github.com/sqlectron/sqlectron-gui/issues/277. But that still has not been implemented yet. In that case, I believe you could just strip that out of the file system stored data.
Sorry, when I wrote down the description for this bug below. I knew it wasn't clear, but I was so lazy that I was hoping you could understand it 😆

The restoring state from a database connection that is not the initial one fails

Let's say I have a server with 2 databases: A and B; and have configured in the server connection to A be the initial database.

I open the connection to that server which will automatically open a tab to database A.
I select the database B in the sidebar and write down a query into the tab to database B.
I close the whole server connection.
I connect again to that server. It will start to fail the connection loading.
I force to close the app.
I open the app again and change that server connection setting to use database B as the initial one.
I connect again to that server and now the app works.

I guess you just need to open the database connection to all databases related to the restored tabs.Would be even better if we could restore the tabs in a lazy loading approach. Which would only open the database connection if the user selects a tab related to that database. But that makes the implementation more complicated. So, I'm ok with the first approach.

By this quote below, did you mean it will not include the context menu queries?

In hindsight I would've introduced some unwanted behaviour in saving the state had I not done that.
I believe on MySQL Workbench it restores all tabs, even the empty ones. I think that is a more expected behaviour at least.

I should've been clearer there, sorry.
Now that I actually know what selectedQuery is (the hilighted text), I noticed if I hilighted a statement, hit cmd+enter to execute it, quit the app and re-opened, selectedQuery was still the statement I had previously hilighted, but I wasn't restoring the hilighting.
So if I had two statements:
SELECT * FROM users;```

and I hilighted the first and ran it, then I only execute the first. When re-opening the app, nothing is hilighted but when I execute it would only be executing the first.

So I need to do one of two things:

1. Figure out how to restore the hilighting in the UI
2. Clear selectedQuery so executing will just execute the whole block and let the user hilight a specific query again

I opted for 2 since it felt easier.

On the other bug,  I fully understand it now, it's outside my normal workflow in the app so I forgot all about testing that.

Fixing that was a big challenge.

I re-set `ConnActions.connect` back to what it was before... I initially tied into it since itw as the first action that runs.

Instead I added a new action, `ConnActions.restoreStoredQueries` which takes a server id as a param.

I updated `QueryBrowser` to dispatch that on `componentWillMount` instead of the `connect` action. This new action grabs the stored state and loops through each database tabs were open for and dispatches `connect` for each of them.

In the event that there's no stored state it just dispatches `connect` for the passed in id, which will then connect to the default database.

To get around the `componentWillReceiveProps` in `QueryBrowser` navigating me back to `/` when I restored query, I had to have the reducer for `connection` set `connecting` to `true` when dispatching `SET_STORED_QUERIES` -- this seemed the simplest way to ensure it knew connections were pending, because `SET_STORED_QUERIES` would dispatch before any `CONNECTION_REQUEST` actions due to the async calls in the `connect` function.

Related to the "select" issue. I agree the second approach seems a better option.
Ok, it is looking better. But I have found other 2 bugs 😢
1. Is not resetting the lastCreatedId prop from reducer/queries when there are no tabs to be restored
Makes sense to keep the lastCreatedId when there are tabs to be restored. But it is weird to keep that value if there are no tabs to restore.
To reproduce the bug:

connect to a server
open 3 tabs and close them all
disconnect from that server
connect to that server again
It will start from query Id 4 instead of from 1.

2. Is loading the same database info (tables, views, etc.) from the selected tab to all databases
To reproduce the bug:

connect to a server:
open a tab for database A and type down a query into it
open a tab for database B and type down a query into it
disconnect from that server
connect to that server again
take a look in the sidebar, both databases will have the same data

I added a commit fixing the first -- Any reason you think that change might break something else?
I seem to be calling back the correct tables when opening a brand new connection (as the app currently does) as well as calling back the correct tables on all databases I'm opening when restoring previous state.
I think the rational for the original line was the currentQueryId when that function would fire was always the newly spawned tab, but when restoring I'd need the tables for both.

@maxcnunes Can you please release this feature? 🙏

I wasn't able to test it again. I got very busy at work these last days. I will test it as soon as I get some free time.

Sorry @s-kem, I have been traveling and I will not have time to review it for the next month. Since you have been helping a lot in the project. I will make you a contributor 🎉
Let's just wait like a week if someone else can review it. Otherwise, you can go ahead and merge it.

Hey @BornaP, would be awesome if you could take a look on this one too 😅

Hehe, this one has a looong history :) I'll take a look as soon as possible.
Congrats @s-kem for joining contributors crew ;)

Hey @BornaP , sorry, been a crazy week.
I did test it out on my work databases and it appears to be loading the data as needed, but most of them didn't have anything to fill out all the categories anyway.
Let me know if you can think of anything else this needs.

@s-kem sorry we couldn't merge your PR. I plan to work on this feature now, but I will be following a slight different approach so I will need to close your PR. I appreciate all the work you have put into this though ❤


fix/http-trigger-with-encrypted-body

closes #104

@loicmathieu & @anna-geller I'm unsure it's the way we want to handle this issue. Basically the old version isn't working as we have an encryptedBody the whole way long (meaning that even in responseCondition we should use encryptedBody) but we don't decrypt it before evaluating the responseCondition.
We can keep that behaviour but add a decrypt step (however it would imply that we move the decrypt method visibility to public in RunContext @loicmathieu) or do as I did here where we execute the request without asking to encrypt body, then we encrypt it before creating the execution from trigger.
The only con I see with that is the discrepancy for reaching out the body as responseCondition is positioned before the encryption (so we reach it out with .body) while in tasks we get a .encryptedBody from trigger variable

@anna-geller FYI after discussion with Loïc, we came to the point that it wasn't a security issue to put decrypt method as public in the runContext which allow the trigger task to keep calling Request task with encrypted body and decrypt it on the fly before evaluating the responseCondition