dasTanmoy0096 commented on PR #9098:
URL: https://github.com/apache/netbeans/pull/9098#issuecomment-3688340165
Thanks for the suggestions, did the following:-
1) Squashed all commits into a single one with a proper description
2) Changed my email from the no-reply email to the real one
What I did not do:-
1) Update gson lib; as the version that's being consumed by LSP/DAP is
independent from the other versions and seems to be working fine; but I can try
updating them (as well as other libaries) in a separate scope.
2) The failing LSP Tests. Regarding the following Assertion Errors:-
```
junit.framework.AssertionFailedError: expected:<1> but was:<2>
[junit] at junit.framework.Assert.fail(Assert.java:57)
[junit] at junit.framework.Assert.failNotEquals(Assert.java:329)
[junit] at junit.framework.Assert.assertEquals(Assert.java:78)
[junit] at junit.framework.Assert.assertEquals(Assert.java:234)
[junit] at junit.framework.Assert.assertEquals(Assert.java:241)
[junit] at
junit.framework.TestCase.assertEquals(TestCase.java:384)
[junit] at
org.netbeans.modules.java.lsp.server.protocol.ServerTest$52.configuration(ServerTest.java:5917)
```
and
```
Testcase:
testChangeMethodParameters(org.netbeans.modules.java.lsp.server.protocol.ServerTest):
FAILED
[junit] expected:<2> but was:<1>
[junit] junit.framework.AssertionFailedError: expected:<2> but was:<1>
[junit] at
org.netbeans.modules.java.lsp.server.protocol.ServerTest.testChangeMethodParameters(ServerTest.java:4739)
[junit] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[junit] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at
org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:84)
[junit] at
org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:489)
[junit] at
org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:410)
[junit] at java.base/java.lang.Thread.run(Thread.java:840)
```
Am not exactly sure what exactly are the issues as the entire IDE itself is
building on my end and all the tests are passing without any errors. An answer
from Copilot tells me the following:-
> That failure is coming from the test’s LSP client stub in
[ServerTest.java:5916-5923](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html):
it intercepts every server→client
[workspace/configuration](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
request and assumes the server will always ask for exactly one configuration
key per request.
>
> In CI, the server sometimes legitimately sends a
[ConfigurationParams](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
with two
[ConfigurationItem](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)s,
so your hard assertion [assertEquals(1,
configurationParams.getItems().size())](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
fails.
>
> Why it can be 2 in CI but not locally (most likely)
>
> The server has two different code paths that call
[client.configuration(new
ConfigurationParams(items))](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html):
> “Normal” single-key fetch via
[ClientConfigurationManager.java:108-151](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
(your inlay-hints path: one key → one item).
> “Refresh all scoped values after config change” via
[ConfigValueCache.java:80-115](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html),
which builds a list of ConfigurationItem for every remembered scope for that
section and sends them in one request.
> In your testInlayHints, you call didChangeConfiguration(...) multiple
times after requesting hints. That triggers
[handleConfigurationChange(...)](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
→
[ConfigValueCache.updateCache(...)](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html),
which may request configuration for all scopes it has cached so far.
> Whether the cache ends up with one scope or two can vary by
environment/timing, because scope computation depends on project/workspace
resolution inside
[ClientConfigurationManager.java:108-126](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
(it calls
[getProjectFromFileScope(scope)](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)).
If CI resolves the file to a “project URI” in one moment and to a “workspace
folder URI” (or a different project identity) in another moment, you can end up
with two distinct scope keys stored for the same config section. Then
[updateCache](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
refreshes both at once → [items.size() ==
2](vscode-file://vscode-app/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html).
> So the test is brittle: it’s not only validating “the inlay hint key is
requested”, it’s also (unintentionally) asserting “the server will never batch
configuration requests / never refresh multiple scopes in one call”, which is
not a stable guarantee.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
