pythonTestAdapter fails if sockets are disabled for tests

Type: Bug

Behaviour
Expected vs. Actual
Actual
When using pytest with pytest_socket to disable network connections in test, the test suite fails. Test Results displays the following error:

vscode_pytest.VSCodePytestError: Error attempting to connect to extension communication socket[vscode-pytest]: A test tried to use socket.socket.connect() with host "localhost" (allowed: "localhost").

Meanwhile, the test suite passes with on the terminal with:
pytest --disable-socket

The test suite can be made to pass by opting out of the pythonTestAdapter experiment in Settings:
"python.experiments.optOutFrom": ["pythonTestAdapter"],

Expected
The test runner succeeds like the CLI.
Steps to reproduce:
I've created a minimal reproduction repo:
https://github.com/johnchristopherjones/vscode-python-test-adapter-socket
The really short version is:

Install pytest_socket
Decorate a test with @pytest.mark.disable_socket:

@pytest.mark.disable_socket
def test_example():
    assert True

Try to run the test with the test runner. (⌘; C)

Or, alternatively:

Install pytest_socket

Add this to your pyproject.toml:
[tool.pytest.ini_options]
addopts = [
    "--disable-socket",    # Disable network in test with pytest-socket

Try to run any tests. (⌘; A)

Diagnostic data

Python version (& distribution if applicable, e.g. Anaconda): 3.11.6
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Venv
Value of the python.languageServer setting: Pylance

Output for Python in the Python Test Log panel

Starting now, all test run output will be sent to the Test Result panel, while test discovery output will be sent to the "Python" output channel instead of the "Python Test Log" channel. The "Python Test Log" channel will be deprecated within the next month. See https://github.com/microsoft/vscode-python/wiki/New-Method-for-Output-Handling-in-Python-Testing for details.CLIENT: Server listening on port 50821...
Received JSON data in run script
============================= test session starts ==============================
platform darwin -- Python 3.11.6, pytest-7.4.3, pluggy-1.3.0
rootdir: /Users/jcj/src/vscode-python-test-adapter-socket
configfile: pyproject.toml
plugins: socket-0.6.0
collected 1 item

tests/test_always_fail.py Error attempting to connect to extension communication socket[vscode-pytest]: A test tried to use socket.socket.
If you are on a Windows machine, this error may be occurring if any of your tests clear environment variables as they are required to communicate with the extension. Please reference https://docs.pytest.org/en/stable/how-to/monkeypatch.html#monkeypatching-environment-variablesfor the correct way to clear environment variables during testing.

INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 721, in send_post_request
INTERNALERROR>     __socket.connect()
INTERNALERROR>   File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/testing_tools/socket_manager.py", line 32, in connect
INTERNALERROR>     self.socket = socket.socket(
INTERNALERROR>                   ^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pytest_socket.py", line 80, in __new__
INTERNALERROR>     raise SocketBlockedError()
INTERNALERROR> pytest_socket.SocketBlockedError: A test tried to use socket.socket.
INTERNALERROR>
INTERNALERROR> During handling of the above exception, another exception occurred:
INTERNALERROR>
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/main.py", line 271, in wrap_session
INTERNALERROR>     session.exitstatus = doit(config, session) or 0
INTERNALERROR>                          ^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/main.py", line 325, in _main
INTERNALERROR>     config.hook.pytest_runtestloop(session=session)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
INTERNALERROR>     return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 152, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_result.py", line 114, in get_result
INTERNALERROR>     raise exc.with_traceback(exc.__traceback__)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 77, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>           ^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/main.py", line 350, in pytest_runtestloop
INTERNALERROR>     item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
INTERNALERROR>     return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 152, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_result.py", line 114, in get_result
INTERNALERROR>     raise exc.with_traceback(exc.__traceback__)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 77, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>           ^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 114, in pytest_runtest_protocol
INTERNALERROR>     runtestprotocol(item, nextitem=nextitem)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 133, in runtestprotocol
INTERNALERROR>     reports.append(call_and_report(item, "call", log))
INTERNALERROR>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/runner.py", line 226, in call_and_report
INTERNALERROR>     hook.pytest_runtest_logreport(report=report)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
INTERNALERROR>     return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 113, in _multicall
INTERNALERROR>     raise exception.with_traceback(exception.__traceback__)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 77, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>           ^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/terminal.py", line 574, in pytest_runtest_logreport
INTERNALERROR>     *self.config.hook.pytest_report_teststatus(report=rep, config=self.config)
INTERNALERROR>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
INTERNALERROR>     return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 152, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>            ^^^^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_result.py", line 114, in get_result
INTERNALERROR>     raise exc.with_traceback(exc.__traceback__)
INTERNALERROR>   File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 62, in _multicall
INTERNALERROR>     next(wrapper_gen)  # first yield
INTERNALERROR>     ^^^^^^^^^^^^^^^^^
INTERNALERROR>   File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 233, in pytest_report_teststatus
INTERNALERROR>     execution_post(
INTERNALERROR>   File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 660, in execution_post
INTERNALERROR>     send_post_request(payload)
INTERNALERROR>   File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 732, in send_post_request
INTERNALERROR>     raise VSCodePytestError(error_msg)
INTERNALERROR> vscode_pytest.VSCodePytestError: Error attempting to connect to extension communication socket[vscode-pytest]: A test tried to use socket.socket.
Error attempting to connect to extension communication socket[vscode-pytest]: A test tried to use socket.socket.
If you are on a Windows machine, this error may be occurring if any of your tests clear environment variables as they are required to communicate with the extension. Please reference https://docs.pytest.org/en/stable/how-to/monkeypatch.html#monkeypatching-environment-variablesfor the correct way to clear environment variables during testing.

Traceback (most recent call last):
  File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 721, in send_post_request
    __socket.connect()
  File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/testing_tools/socket_manager.py", line 32, in connect
    self.socket = socket.socket(
                  ^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pytest_socket.py", line 80, in __new__
    raise SocketBlockedError()
pytest_socket.SocketBlockedError: A test tried to use socket.socket.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/run_pytest_script.py", line 67, in <module>
    pytest.main(arg_array)
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/config/__init__.py", line 169, in main
    ret: Union[ExitCode, int] = config.hook.pytest_cmdline_main(
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
    return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
    return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 113, in _multicall
    raise exception.with_traceback(exception.__traceback__)
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 77, in _multicall
    res = hook_impl.function(*args)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/main.py", line 318, in pytest_cmdline_main
    return wrap_session(config, _main)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/main.py", line 306, in wrap_session
    config.hook.pytest_sessionfinish(
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
    return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
    return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 130, in _multicall
    teardown[0].send(outcome)
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/_pytest/terminal.py", line 857, in pytest_sessionfinish
    outcome.get_result()
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_result.py", line 114, in get_result
    raise exc.with_traceback(exc.__traceback__)
  File "/Users/jcj/src/vscode-python-test-adapter-socket/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 77, in _multicall
    res = hook_impl.function(*args)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 367, in pytest_sessionfinish
    execution_post(
  File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 660, in execution_post
    send_post_request(payload)
  File "/Users/jcj/.vscode/extensions/ms-python.python-2023.19.13031019/pythonFiles/vscode_pytest/__init__.py", line 732, in send_post_request
    raise VSCodePytestError(error_msg)
vscode_pytest.VSCodePytestError: Error attempting to connect to extension communication socket[vscode-pytest]: A test tried to use socket.socket.
Starting now, all test run output will be sent to the Test Result panel, while test discovery output will be sent to the "Python" output channel instead of the "Python Test Log" channel. The "Python Test Log" channel will be deprecated within the next month. See https://github.com/microsoft/vscode-python/wiki/New-Method-for-Output-Handling-in-Python-Testing for details.

User Settings

languageServer: "Pylance"

testing
• pytestEnabled: true

terminal
• launchArgs: "<placeholder>"

Extension version: 2023.19.13031019
VS Code version: Code 1.83.1 (f1b07bd25dfad64b0167beb15359ae573aecd2cc, 2023-10-10T23:57:32.750Z)
OS version: Darwin arm64 22.6.0
Modes:

Hello! What is the reason you want to disable sockets? The sockets are how we send information on the run status back to the Python extension and gather test results. Therefore it would require some design changes to fix this.

@eleanorjboyd It looks like https://pypi.org/project/pytest-socket/ plugin specifically used for disabling sockets for testing.

@eleanorjboyd As @karthiknadig mentioned, sockets are disabled by the pytest-socket plugin for pytest, which is a good practice to ensure the code under test is not opening unexpected network connections. For instance, when testing code that might exercise a third-party API, you want to make sure your test suite isn't REALLY sending requests to that API—especially if your test suite runs in CI.
As I mention in my reproduction repo, I suspect this might have a straightforward cause and possibly a straightforward fix. The vscode_pytest/run_pytest_script.py script is directly invoking pytest.run() in-process. That means the script itself is being subjected to the test suite, which can include all kinds of very reasonable modifications for test suites that are not at all reasonable for production code, such as patching os.environ and very routine test activities such as opening and closing any number of sockets and files.
I think the test adapter script shouldn't run in the same process as the test suite. Consider spinning off a subprocess, perhaps with asyncio.subprocess.

Just for reference, here are some of the Python testing libraries that patch socket.socket:

Package
Oct 2023 Downloads
Testing
Pytest Plugin
Useful in Prod?

pytest-socket
588k
✅
✅
❌

httpretty
487k
✅
❌
✅

pytest-recording
144k
✅
✅
❌

pytest-network
13k
✅
✅
❌

It's also relatively common to just patch socket.socket yourself. For extra convenience and safety, the standard library comes with unittest.mock. That is, a library isn't really necessary, so library usage is an incomplete measure of the impact.

Hello! Thank you for the information as it provides important data about this problem. Would named pipes be a sufficient work-around here or do you anticipate that not working for the libraries you listed above?

@eleanorjboyd As in os.mkfifo? I'm not very experienced with it. With some quick testing, it does appear to work.
N.B.: The docs effective say it requires a POSIX system. Specifically:

Availability: Unix, not Emscripten, not WASI.

No idea if that affects non-WSL Windows or vscode.dev.

@johnchristopherjones On the python side we won't be using os.mkfifo, for our scenarios. The pipes will created on the node side. The plan is to create pipe on node side, windows supports named pipes via node net package, and we will use fs.mkfifo to create named pipes for non-windows.
On the python side, it is enough to use open with r+b flags to get a read write stream to the pipes on all os'es.

@johnchristopherjones, we will look to work on this change soon but cannot promise a timeline. @karthiknadig or I will keep you in the loop as we merge changes related to switching to named pipes. Thanks!

Hi @johnchristopherjones 👋
It's not a bug in vscode-python, but a bug in pytest-socket. I have opened this PR to resolve the issue: https://github.com/miketheman/pytest-socket/pull/275

Current workaround
Downgrade your version of pytest-socket to the previous version: 5.1.0.

@magnasilvar Thanks for the tip. However, I think that's a separate bug. It's related insofar as that bug prevents a partial workaround using --allow-hosts=localhost with pytest-socket.
That's not a workaround I want to use because I also specifically don't want connections to services running on localhost, like databases.
Allowing localhost would allow the test runner to work, much like turning off your firewall or setting a DMZ allows friends to connect to your Minecraft server—you're just circumventing the firewall. The underlying problem is that the test runner runtime environment is being controlled by the test suite environment.
Consider the following use-cases:

You want to fail tests that open connections to a local development database (e.g., postgres on localhost:5432)
You want to fail tests that open unix sockets for IPC, because you're trying to verify the code is free of side-effects. Localhost is not relevant because there's no networking protocol involved. (You can also connect to postgres on unix-domain sockets.)

Relatedly, we closed #21645, regarding pytest-recording breaking under the new test runner, with this understanding. Is it the same bug in pytest-recording? Maybe, but they're not dependencies of each other, so fixing one won't fix the other.

Any updates here. I'm wondering what significant changes have been made to pytest in the last month to cause issues like this, and who knows what else.

hi @shanewazabbas, are you asking about changes in the last month since you are just not seeing this issue? We have made limited changes this month (I have been out of office) but we did increase the number of people in the new testing rewrite so that could see the problem. If you opt out of the rewrite does that fix it?
just add this to your user settings.json "python.experiments.optOutFrom": ["pythonTestAdapter"],.
Thanks

hey @eleanorjboyd:

we did increase the number of people in the new testing rewrite so that could see the problem.

Ahhh that explains it. When I saw below logs, I thought python extension updated but didn't see any release updates so I was confused:
Starting now, all test run output will be sent to the Test Result panel,
while test discovery output will be sent to the "Python" output channel instead of
the "Python Test Log" channel.  The "Python Test Log" channel will be deprecated within the next month.
See https://github.com/microsoft/vscode-python/wiki/New-Method-for-Output-Handling-in-Python-Testing for details.
PYTEST ERROR: TEST_UUID and/or TEST_PORT are not set at the time of pytest starting.
Please confirm these environment variables are not being changed or removed as they are
required for successful test discovery and execution.
TEST_UUID = xxxx
TEST_PORT = xxx

Btw something to think about regardless of the update, is performance of test discovery for large monorepos (like really large). Cause it reruns that collection logic on save, which I dont think is practical in all cases. Unless theres work being done to make collection discovery reuse previous results? Unclear on the roadmap for the new changes.

Hi, thanks for the follow up. A few notes:
PYTEST ERROR: TEST_UUID and/or TEST_PORT are not set at the time of pytest starting.
Please confirm these environment variables are not being changed or removed as they are
required for successful test discovery and execution.
TEST_UUID = xxxx
TEST_PORT = xxx

this error message is accidental, the extension is working fine I put this error message in an incorrect spot. The fix is in insiders and will be out with our next stable release in about a week.
secondly, you can update the settings so it no longer re-runs discovery on save- would this help in your case? The idea of reusing discovery results is a complicated one so we haven't approached that topic yet. One thing we did consider was only running discovery on the file you save instead of discovery on the whole workspace. Would something like this be another solution to your issue?
Thanks

The fix is in insiders and will be out with our next stable release in about a week.

Good to know thanks.

update the settings so it no longer re-runs discovery on save

Ah ok, I'll look into that.

One thing we did consider was only running discovery on the file you save instead of discovery on the whole workspace.

Yeah that would definitely solve it for me 👍 , if that is possible with pytest. Cause it would greatly help with my dev time.

created this issue for the discovery on only specifically the saved file: https://github.com/microsoft/vscode-python/issues/22582.

Thanks! Not sure how open source this is, but If there's a way for me to contribute towards this, then let me know. I can try. Like a pull request with a rough implementation or something. If not I'll just vote the issue.

Yes this extension is completely open source. Lets hop over the other issue to continue our discussion but I'll put together a PR outlining what steps I think need to be taken.

I have been hit by this in some projects where sockets are disabled by design. Took a very long time to figure it out :(

just add this to your user settings.json "python.experiments.optOutFrom": ["pythonTestAdapter"],.

The issue goes away when I opt out from the experiment.

Same problem here but optOut parameter seems no more known:

Should we put that into the settings.json ?

Hello no it don't work for me.
what do you means by:

not the one for the given workspace

I have only one settings.json in the .vscode repo

And the content is:

Note that the option is grayed.

Ok I finally found it. For those like me you should Go to the menu Preferences / Settings. Search the "extensions" section, find "Python", search Opt Out Form (with blank else you won't find it) and edit in settings.json. Then add the "PythonTestAdapter" at the right place.

And the tests are now ok.
Very not easy to find...

You can also use the command palette to go the the user settings json and add it there

Hello! What is the reason you want to disable sockets? The sockets are how we send information on the run status back to the Python extension and gather test results. Therefore it would require some design changes to fix this.

As others have noted, disabling all network activity in a unit test is critical for repeatability (google for "hermetic unit test").  And that's what pytest-socket does for you.  Doing
   "python.experiments.optOutFrom": [
        "pythonTestAdapter"
    ]

did indeed work around the problem for me, but it really shouldn't be necessary.  I get that you want to talk to the mother ship to manage A/B experiments, but it seems like that could (and should) be done outside the test setup context.

@roysmith This issue has nothing to do with communication with experimentation server. The new test adapter uses socket connection to communicate VS Code UI to show live test status, and it fails to connect with VS Code to provide that info. The optOutFrom setting internally switches which (old vs new) adapter is used.

@roysmith This issue has nothing to do with communication with experimentation server. The new test adapter uses socket connection to communicate VS Code UI to show live test status, and it fails to connect with VS Code to provide that info. The optOutFrom setting internally switches which (old vs new) adapter is used.

OK, I accept that I incorrectly analyzed the root cause, but the gist is still the same; it shouldn't be necessary to do this to these kinds of tests working.

Hello! We have now switched our extension to using named pipes! This should resolve the socket disabled issue. If someone could try it out and let me know if it works that would be extremely helpful. To do so you just need to be on the latest version of the python insiders extension and a vscode version >= 1.89.0-20240415- the easiest way to do this is download vscode insiders and get the pre-release of the python extension.
Thanks so much and happy coding!

@eleanorjboyd  Thanks for working on this.  I just installed Code - Insiders and can confirm that my tests fail with v2024.4.1 but pass with v2024.5.11101014 (pre-release), so all looks good.

Great! Thanks so much for confirming!

I'm now receiving errors about the named pipe connection:
INTERNALERROR>     raise VSCodePytestError(error_msg)
INTERNALERROR> vscode_pytest.VSCodePytestError: Error attempting to connect to extension named pipe /tmp/python-test-results-9d6ff019c19cfd28e658.sock[vscode-pytest]: A test tried to use socket.socket.connect() with host "None" (allowed: "<IP_ADDRESS>").
Error attempting to connect to extension named pipe /tmp/python-test-results-9d6ff019c19cfd28e658.sock[vscode-pytest]: A test tried to use socket.socket.connect() with host "None" (allowed: "<IP_ADDRESS>").
If you are on a Windows machine, this error may be occurring if any of your tests clear environment variables as they are required to communicate with the extension. Please reference https://docs.pytest.org/en/stable/how-to/monkeypatch.html#monkeypatching-environment-variablesfor the correct way to clear environment variables during testing.

Traceback (most recent call last):
  File "/home/vscode/.vscode-server-insiders/extensions/ms-python.python-2024.5.11101014/python_files/vscode_pytest/__init__.py", line 780, in send_post_request
    __writer.connect()
  File "/home/vscode/.vscode-server-insiders/extensions/ms-python.python-2024.5.11101014/python_files/testing_tools/socket_manager.py", line 27, in connect
    self._socket.connect(self.name)
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pytest_socket.py", line 224, in guarded_connect
    raise SocketConnectBlockedError(allowed, host)
pytest_socket.SocketConnectBlockedError: A test tried to use socket.socket.connect() with host "None" (allowed: "<IP_ADDRESS>").

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/vscode/.vscode-server-insiders/extensions/ms-python.python-2024.5.11101014/python_files/vscode_pytest/run_pytest_script.py", line 66, in <module>
    pytest.main(arg_array)
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/_pytest/config/__init__.py", line 169, in main
    ret: Union[ExitCode, int] = config.hook.pytest_cmdline_main(
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
    return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
    return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 113, in _multicall
    raise exception.with_traceback(exception.__traceback__)
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 77, in _multicall
    res = hook_impl.function(*args)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/_pytest/main.py", line 318, in pytest_cmdline_main
    return wrap_session(config, _main)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/_pytest/main.py", line 306, in wrap_session
    config.hook.pytest_sessionfinish(
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_hooks.py", line 493, in __call__
    return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_manager.py", line 115, in _hookexec
    return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 130, in _multicall
    teardown[0].send(outcome)
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/_pytest/terminal.py", line 857, in pytest_sessionfinish
    outcome.get_result()
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_result.py", line 114, in get_result
    raise exc.with_traceback(exc.__traceback__)
  File "/workspaces/homeassistant-elasticsearch/.venv/lib/python3.11/site-packages/pluggy/_callers.py", line 77, in _multicall
    res = hook_impl.function(*args)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vscode/.vscode-server-insiders/extensions/ms-python.python-2024.5.11101014/python_files/vscode_pytest/__init__.py", line 385, in pytest_sessionfinish
    execution_post(
  File "/home/vscode/.vscode-server-insiders/extensions/ms-python.python-2024.5.11101014/python_files/vscode_pytest/__init__.py", line 723, in execution_post
    send_post_request(payload)
  File "/home/vscode/.vscode-server-insiders/extensions/ms-python.python-2024.5.11101014/python_files/vscode_pytest/__init__.py", line 791, in send_post_request
    raise VSCodePytestError(error_msg)
vscode_pytest.VSCodePytestError: Error attempting to connect to extension named pipe /tmp/python-test-results-9d6ff019c19cfd28e658.sock[vscode-pytest]: A test tried to use socket.socket.connect() with host "None" (allowed: "<IP_ADDRESS>").

Hi @strawgate, what machine type are you working on and are you mocking out / removing any environment variables?
What I can see from your logs is the extension knows the named pipe because it lists it here:vscode_pytest.VSCodePytestError: Error attempting to connect to extension named pipe /tmp/python-test-results-9d6ff019c19cfd28e658.sock[vscode-pytest]:. So the name is know in the error message which is a line after the attempted connection fails with the name being None.
 if __writer is None:
        try:
            __writer = socket_manager.PipeManager(TEST_RUN_PIPE)
            __writer.connect()
        except Exception as error:
            error_msg = f"Error attempting to connect to extension named pipe {TEST_RUN_PIPE}[vscode-pytest]: {error}"
            print(error_msg, file=sys.stderr)

@karthiknadig thoughts?

I suspect that the pytest_socket pligin is getting loaded before vscode_pytest. One thing you could try is to disable Unix Domain socket from being blocked by the pytest_socket plugin. It may have a optional setting to do this.

One thing you could try is to disable Unix Domain socket from being blocked by the pytest_socket plugin. It may have a optional setting to do this.

I'm just observing this as a bystander, but I do see that pytest-socket does allow for that:

[pytest]
addopts = --disable-socket --allow-unix-socket

I also see you can configure it to only allow connections to (for example) localhost, which might be another possible workaround:

[pytest]
addopts = --allow-hosts=<IP_ADDRESS>,<IP_ADDRESS>

Hi @strawgate, what machine type are you working on and are you mocking out / removing any environment variables?
What I can see from your logs is the extension knows the named pipe because it lists it here:vscode_pytest.VSCodePytestError: Error attempting to connect to extension named pipe /tmp/python-test-results-9d6ff019c19cfd28e658.sock[vscode-pytest]:. So the name is know in the error message which is a line after the attempted connection fails with the name being None.
 if __writer is None:
        try:
            __writer = socket_manager.PipeManager(TEST_RUN_PIPE)
            __writer.connect()
        except Exception as error:
            error_msg = f"Error attempting to connect to extension named pipe {TEST_RUN_PIPE}[vscode-pytest]: {error}"
            print(error_msg, file=sys.stderr)

link
@karthiknadig thoughts?

I'm using a Windows laptop using remote ssh to an Ubuntu 22.04 host and a devcontainer on that Ubuntu host.
I'm not mocking any environment variables and this is the repository I'm running tests from https://github.com/legrego/homeassistant-elasticsearch/tree/main/custom_components

@strawgate One thing you could try is to disable Unix Domain socket from being blocked by the pytest_socket plugin. It may have a optional setting to do this.

I did try this with no luck

I was able to fix this error by turning off telemetry (added the following to my settings.json)
"telemetry.telemetryLevel": "off",

@phil-bell The issue is with pytest_socket and similar plugins, interfering with vscode_pytest plugin for testing, where it fails to show results. This only happens on Unix now because named pipes use sockets to communicate.
@strawgate  We have a tracking issue to change the communication channel from UDS to fifo that should address the problem. For your case the pytest_socket package is loading up before vscode_pytest and is patching the socket APIs from python.


Error: constructor FlowUIFragment() is already defined in class FlowUIFragment

Not sure what is causing this, but it is preventing me from launching my app in the Android emulator:
warning: [options] source value 1.5 is obsolete and will be removed in a future release
warning: [options] target value 1.5 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
build/android/Development-23/java/com/yourcompany/calagator/FlowUIListViewAdapter.java:11: error: constructor FlowUIListViewAdapter() is already defined in class FlowUIListViewAdapter
	public FlowUIListViewAdapter() { super(); }
	       ^
build/android/Development-23/java/com/yourcompany/calagator/ReachabilityDelegate.java:9: error: constructor ReachabilityDelegate() is already defined in class ReachabilityDelegate
	public ReachabilityDelegate() { super(); }
	       ^
1 error
3 warnings
1 error
3 warnings
build/android/Development-23/java/com/yourcompany/calagator/FlowUIFragment.java:13: error: constructor FlowUIFragment() is already defined in class FlowUIFragment
	public FlowUIFragment() { super(); }
	       ^
1 error
3 warnings
rake aborted!
Command failed with status (1): [/usr/bin/javac -d "build/android/Developme...]
/Library/RubyMotion/lib/motion/project/template/android.rb:537:in `block (2 levels) in <top (required)>'
/Library/RubyMotion/lib/motion/project/paralel_builder.rb:47:in `call'
/Library/RubyMotion/lib/motion/project/paralel_builder.rb:47:in `block (2 levels) in initialize'
Tasks: TOP => build
(See full trace by running task with --trace)

Hi Andrew, does it reproduce if you clean up everything and try again? There is a well-known bug which manifests when generating the java stubs in an already-built project.

Ah yes, running rake android:clean:all fixed the problem. Thanks!


How to add missed .so libraries ?

I am using Flutter Drift to use SqlLite and I have this exception at runtime :
Waiting for observatory port to be available...
[   +5 ms] [E] [WARN][(tid:4596)(_wl_egl_tizen_get_tizen_private)] Should create tpl_surface with this wl_egl_window first.
[   +2 ms] [WARN][(tid:4596)(_wl_egl_tizen_get_tizen_private)] All wl_egl_window_tizen APIs will be ignored.
[        ] [E] [WARN][(tid:4596)(wl_egl_window_tizen_set_buffer_transform)] wl_egl_window(0x815ee620) wl_output_transform(0) already rotated
[        ] [WARN][(tid:4596)(wl_egl_window_tizen_set_window_transform)] wl_egl_window(0x815ee620) window_transform(0) already rotated
[   +1 ms] [E] [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Invalid argument(s): Failed to load dynamic library 'libsqlite3.so': libsqlite3.so: cannot open shared object file: No such file or directory
[   +1 ms] #0      _open (dart:ffi-patch/ffi_dynamic_library_patch.dart:12:43)
[        ] #1      new DynamicLibrary.open (dart:ffi-patch/ffi_dynamic_library_patch.dart:23:12)
[        ] #2      _defaultOpen (package:sqlite3/src/ffi/load_library.dart:52:27)
[        ] #3      OpenDynamicLibrary.openSqlite (package:sqlite3/src/ffi/load_library.dart:127:12)
[        ] #4      sqlite3 (package:sqlite3/src/ffi/api/sqlite3.dart:11:38)
[        ] #5      _NativeDelegate.openDatabase (package:drift/native.dart:155:12)
[        ] #6      Sqlite3Delegate._createDatabase (package:drift/src/sqlite3/database.dart:73:11)
[        ] #7      Sqlite3Delegate.open (package:drift/src/sqlite3/database.dart:61:7)

The main error is :
Unhandled Exception: Invalid argument(s): Failed to load dynamic library 'libsqlite3.so': libsqlite3.so: cannot open shared object file: No such file or directory
How to add these libraries ?
And the tizen tools shoudn't add them automatically ?

A libsqlite3.so.0 binary is already shipped with every Tizen device, so the simplest way would be overriding sqlite3's loading path by calling open.overrideFor when your app starts (e.g. in the main function of your app). Please refer to https://github.com/flutter-tizen/plugins/issues/277#issuecomment-992126520 for the full example.
The libsqlite3.so.0 shipped with the device is fairly old and thus may not support features needed by the Drift package. If you have your own libsqlite3.so built for your device's architecture (armel), you can copy the binary to your app's tizen\lib directory and it will be packaged along with your app into a TPK.
Another option is to use the sqflite package, if you don't specifically need to use Drift. Both packages are marked "Flutter Favorite" but I don't know which one is superior.

Thank you @swift-kim It's impossible to rewrite the project with another framework, I already tried to put all "*.so" in the lib folder, it didn't works, but I am not sure in which architecture they were compiled.
Thank you very much for the response, I should fix it with these informations,

Hi @swift-kim , I have these build architecture :
- arm64-v8a
- armeabi-v7a
- x86
- x86-x64

I guess the arm64-v8a or armeabi-v7a , one of them could be compatible with the "armel" architecture  ?
I am not interested in the Armel Architecture, I just want to be able to build to the Samsung TV OS.

Hi @swift-kim , No matter wich library I put in the tizen\lib it still saying
Failed to load dynamic library 'libsqlite3.so': libsqlite3.so: cannot open shared object file: No such file or directory
I think the folder is not working at all

ok I will try, thanks

Hi again, I don't understand what did make you understand that my device architecture is ARMEL, my emulator is TV-SAMSUNG-x86 when I run the build, I see :
executing: C:\tizen-studio\tools\ide\bin\tizen.bat build-native -C Debug -a x86
So I don't understand it should be x86 as the device architecture, but indeed when I put the x86 libraries, it dosn't work but the open.overrideFor seemes working so I don't understand !

If you're on an emulator, yes, the architecture is x86. (If you're on a real TV device, the architecture is armel.)
The architecture is not the only condition for DynamicLibrary.open to succeed. For example, the "soname" (not the file name) of your library must exactly be libsqlite3.so. (You can check this with readelf -d on Unix but I don't know how to do it on Windows.) Also all of its dependencies must be present on your device at runtime. If the binary has not been built with the Tizen SDK toolchain, it's unlikely the dependencies are all present on Tizen devices.
Anyway, no further explanation should be necessary. Please just use open.overrideFor.

@swift-kim thanks, I got it :), I need undertand it because it's not the only library I need to load, I need VLC also, so thanks again.

You're welcome. If you need more help, please let us know. :)


Hostname is still example.com after update to nginx.conf

I am running on a non-standard docker environment (docker-compose w/ lima & containerd), however I've ventured into the shynet_webserver container using lima nerdctl exec -it shynet_webserver /bin/sh and inspected the nginx.conf that is copied over to /etc/nginx/conf.d/default.conf and verified that the hostname in both files points to the host name I want: analytics.haze.cool. Despite these modifications, the hostname on the site is still broadcasted as example.com. Am I missing a crucial step somewhere? (I've been following the docker-compose setup in GUIDE.md)

I'll be completely honest here.. I meant to create this in another repository and have no idea how I managed to create this here. Apologies! (although it still may be relevant)


Either switch from poetry to flit, or add an option for flit/poetry flavour

https://github.com/chris48s/pip-abandoned is a pretty good model for this
~Side note: You had to copy & paste https://github.com/chris48s/python-package-shared/blob/main/action.yml because it is a coupled to poetry. It would be nice to sort out https://github.com/chris48s/python-package-shared/issues/1 in tandem with this.~

2x GitHub workflows:
pre-install: flit

__version__.py needs to exist for flit

.flake8:
exclude = .venv

.gitignore:
# venv
.venv

You could just add those - they won't hurt the poetry template

CONTRIBUTING.md
release.sh

multiple differences

Makefile
pyproject.toml

completely different - probably just want 2 different versions of those files

Everything else is the same

done in https://github.com/chris48s/cookiecutter-python-package/commit/af0e7cf3571fba135ad0abf6c81621c43353dfa5


Noticeable lag when working with images that have a large amount of annotations

This issue is duplicate of #3875
It has been a year since this issue has had any response, I was wondering if there is any update on the matter?
I regularly deal with images that require thousands of labels and after about 600-800 there is a noticeable lag between every single action (selection, creation, deletion, resizing, moving, etc.), sometimes as a large as whole seconds.
As of this moment, I use the latest version in the develop branch.
This issue template is closely related to @WiktorAdamczyk1 's template in the original issue.
My actions before raising this issue

[x] Read/searched the docs
[x] Searched past issues
[x] Tried both the local and web versions
[x] Tried different browsers (Chrome, Brave, Opera, etc.)

Expected Behaviour

UI should be able to handle a large number of annotations on a single image without making every action delayed.
Current Behaviour

Loading an image with hundreds or thousands of annotations takes a long time to load, sometimes resulting in many 'page unresponsive' prompts. Any action on the image is also incredibly delayed (selection, creation, deletion, editing, etc.).
Possible Solution

It seems that the application lags on a larger number of annotations as every action involves a reload/recheck/redraw of everything on the image. Perhaps only update newly created/edited/deleted annotations with each action.
The possible solution brought about in the original issue may also work as well.
Steps to Reproduce (for bugs)

Loading an image:

Load an image with thousands of annotations.
Create/edit/delete an annotation

When annotating a new image:

Create enough annotations (my application starts lagging around 600-800 annotations)
Create/edit/delete an annotation

Context

I deal with images that require a lot of annotations in the form of bounding boxes, as there are many objects that need to be labelled within the image.
Your Environment

Git hash commit (git log -1):

C:\Users\Errin\Documents\work\projects\cvat>git log -1
commit 9f89787f95504474b154974c7ec6087dd13149dd (HEAD -> develop, origin/develop, origin/HEAD)
Author: Maria Khrustaleva<EMAIL_ADDRESS>Date:   Tue Sep 13 11:39:43 2022 +0200
Source & target storage support (#4842)

Docker version docker version (e.g. Docker 17.0.05):

Docker 20.10.17

Are you using Docker Swarm or Kubernetes?

No.

Operating System and version (e.g. Linux, Windows, MacOS):

Windows 10

Code example or link to GitHub repo or gist to reproduce problem:

None

GPU: NVIDIA GeForce GTX 1070
CPU: Intel(R) Core(TM) i7-8750H
RAM: 16GB

Hi, that is true.
UI performance needs to be optimized. We remember about the issue, but currently we do not have enough resources to work on it.
I will close the issue as a duplicate of #3875


Players joining in progress have a mixed sniper packet implementation

New players joining via JIP have the client thinking they have sniper packets and the server not thinking they have sniper packets, resulting in odd behavior including double projectiles.

@tobiasksu sent this video where each player had JIP'd at least once into the match, and clearly shows one client firing both fusion and impulse at the same time.

However, I am unable to reproduce it.  Tobias, are you able to get this to the point where it's 100% reproducible?

I’ve only noticed it just the one time and can’t reproduce

Yuck.  I am 99% positive what is happening is that the server doesn't believe the client has sniper packets, so is simulating their stuff for them, and of course since it's JIP what the server thinks is wrong.  I might have a hacky way of fixing it, but without a way to reproduce it I might just be grasping at straws.

this was possible to happen long before sniper packets came around so i dont think its related

The wrong weapon has been noticed before, but I haven't noticed DOUBLE weapons before, like what Tobias has shown.

y thats what i mean. thunderbolt and flak got fired at the same time but we couldnt reproduce it so i am not even sure if both weapons were able to do damage

I finally reproduced it, and I was partially correct.  It was a mixed sniper packet implementation, but mixed not in the sense that the client and server are in disagreement as to who has sniper packets, but rather mixed in the sense that thunderbolt and all secondaries are treated differently in a non-sniper packet environment than the rest of the weapons.
This also led to me realizing there was a flaw with the sniper packet implementation: players weren't seeing OTHER players' sniper packets for primaries except thunderbolt.  This is all fixed in the commit that closed this issue, and will be in the next version of olmod.
Didn't expect to find and fix this tonight at ALL.


Add tooling to document lints

One thing the linting system has been missing is documentation. There is no list of all cargo's lints and their associated documentation, like clippy or rustc has. To resolve this problem, I wrote a very basic tool that gathers the doc comments for a Lint and copies them to a markdown file in the Cargo book. This solution is not perfect but it is a way to work towards a better overall experience.

@bors r+

:hourglass: Testing commit 7d7b7c2c8bca49b3671eb9ad00c3c9565ed19d18 with merge e8e50d020d06be458fc534a3dcfb5200adb3b8e3...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing e8e50d020d06be458fc534a3dcfb5200adb3b8e3 to master...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing e8e50d020d06be458fc534a3dcfb5200adb3b8e3 to master...

:eyes: Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request.


⚠ GitLab Server has degraded performance

In a989026, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 7035 ms

Resolved: GitLab Server performance has improved in 0e48d8e.


docs/answers.rst: Add docs regarding answers

Reviewers Checklist

[ ] Appropriate logging is done.
[ ] Appropriate error responses.
[ ] Handle every possible exception.
[ ] Make sure there is a docstring in the command functions. Hint: Lookout for
botcmd and re_botcmd decorators.
[ ] See that 100% coverage is there.
[ ] See to it that mocking is not done where it is not necessary.

As a more general comment. You should name elements as something unique so that you can refer to them later in the doc. Naming should be highlighted for quick correlation.

ack https://github.com/coala/corobo/pull/273/commits/d50d13cf1782e55ec45aef74e43a301093f78c37

reack 4478e67

@rultor merge

@rultor merge

@meetmangukiya OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@meetmangukiya Done! FYI, the full log is here (took me 2min)


[Feature?]: @solidjs/start should provide .d.ts

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
@solidjs/start currently points to .ts and .tsx files for resolving type information.
"types": "./shared/index.tsx",
"exports": {
  ".": "./shared/index.tsx",
  "./config": "./config/index.js",
  "./server": "./server/index.tsx",
  "./server/spa": "./server/spa/index.tsx",
  "./client": "./client/index.tsx",
  "./client/islands": "./client/islands.tsx",
  "./middleware": "./server/middleware.ts",
  "./client/spa": "./client/spa/index.tsx"
},
"typesVersions": {
  "*": {
    ".": [
      "./shared/index.tsx"
    ],
    "./server": [
      "./server/index.tsx"
    ],
    "./client": [
      "./client/index.tsx"
    ]
  }
},

Using source .ts files makes skipLibCheck ineffective, leading to errors like this
node_modules/.pnpm/@solidjs+start@0.4.4_rollup@2.79.1_solid-js@1.8.8_vinxi@0.1.1_vite@4.5.1/node_modules/@solidjs/start/shared/dev-overlay/CodeView.tsx:59:18 - error TS2532: Object is possibly 'undefined'.

59     const lang = props.fileName
                    ~~~~~~~~~~~~~~
60       .split(/[#?]/)[0]
   ~~~~~~~~~~~~~~~~~~~~~~~

node_modules/.pnpm/@solidjs+start@0.4.4_rollup@2.79.1_solid-js@1.8.8_vinxi@0.1.1_vite@4.5.1/node_modules/@solidjs/start/shared/dev-overlay/CodeView.tsx:80:11 - error TS18048: 'el' is possibly 'undefined'.

80           el.innerHTML = `<mark style="background-color:#aaaaaa80">${el.innerHTML}</mark>`;
             ~~

node_modules/.pnpm/@solidjs+start@0.4.4_rollup@2.79.1_solid-js@1.8.8_vinxi@0.1.1_vite@4.5.1/node_modules/@solidjs/start/shared/dev-overlay/CodeView.tsx:80:70 - error TS18048: 'el' is possibly 'undefined'.

80           el.innerHTML = `<mark style="background-color:#aaaaaa80">${el.innerHTML}</mark>`;
                                                                        ~~

node_modules/.pnpm/@solidjs+start@0.4.4_rollup@2.79.1_solid-js@1.8.8_vinxi@0.1.1_vite@4.5.1/node_modules/@solidjs/start/shared/dev-overlay/get-source-map.ts:14:20 - error TS2532: Object is possibly 'undefined'.

14     const result = lines[i].match(SOURCEMAP_REGEX);
                      ~~~~~~~~

Expected behavior 🤔
.d.ts files should be built and pointed to in types, exports and typesVersions in package.json.
Source files should still be pointed to for conditional exports such as import and export.
Prior art includes Solid Router and Kobalte.
Steps to reproduce 🕹
Steps:

Open stackblitz
Wait for packages to install
Run pnpm tsc
Observe a lot of errors from @solidjs/router even though skipLibCheck is enabled

Context 🔦
I like doing monorepo-wide typechecking with pnpm tsc -b, but these errors get in the way. I can just run the command from packages that don't depend on @solidjs/start in the meantime.
Your environment 🌎
No response

Yeah we can look at adding a build process. This was a big problem for some projects in the previous version. But there is a lot less code here and while others working on this project might be all for JSDoc .. while I like the result, I generally am not.
There is some tension between the code needed for runtime and the code needed for build time. I need to make sure there isn't cross referencing in a weird way but this should be doable I think.

I was informed this would be problematic for things like the dev overlay. So I'm not sure how feasible this is at this time. I'm not the greatest with typescript and the other developers who contribute the most to the project have been pushing back from having a build process.

That's understandable, but I just want to emphasize how unconventional this setup is. I've worked in a lot of different code bases with tons of different frameworks, and never have I seen a package that ships like this, with type issues in the package itself affecting the end user. Most projects I have worked on enforce passing tsc in CI, meaning a solid-start project would not make it out the door. I do it myself for my hobby projects as well, and for solid-start I consider it okay because of the beta label, but if this is the intended end state for 1.0 as well I'm not sure I'll keep using solid-start. And please read this the right way, I absolutely love solid-start, but this kills my whole workflow which relies a lot on running tsc -w continuously while developing.
I don't have a lot of experience with publishing packages, but these are some ways forward that could alleviate this issue that I can come up with:

Turn on all the strictest settings of typescript and make sure solid-start passes them. I think this is what causes the errors to the user, that they have a more strict typescript config than solid-start has.
Try publishing to jsr.io as well. It's very new and very exciting. You wouldn't have to add a build step, because the registry handles that part. Maybe too unconventional for some, but I would very much consider getting solid-start from there if it alleviated this issue.
Add a build step. I know the team doesn't want to, but honestly this is the same as sacrificing UX for DX, just on a lower level (app author DX vs framework author DX). Thousands of developers feel the pain from this setup at the moment.

Just my 5 cents as a solid-js user since 3 years who really wants solid-start to succeed! 🙂

I think i've managed to add a simple build process using tsc and some manual file copying.
It's available on npm under @brendonovich/solid-start and the code is on my fork

implemented in 0.7.2


Filter options based on another dropdown using pipe

Hi basvandenberg,
im using your library, and i think it's good. but i still have problem to implement filter options based on another dropdown
here is my logic
let obj1 = [
{ value: 1, label: 'a'},
{ value: 2, label: 'b'},
{ value: 3, label: 'c'},
]

let obj2 = [
{ value: 1, label: 'child_label_a', val_obj1: 1},
{ value: 2, label: 'child_label_a', val_obj1: 1},
{ value: 3, label: 'child_label_a', val_obj1: 1},
{ value: 4, label: 'child_label_b', val_obj1: 2},
{ value: 5, label: 'child_label_c', val_obj1: 3},
]

what i want to expect is, if i select dropdown with value = 1 dropdown 2, will show like this
let obj2 = [
{ value: 1, label: 'child_label_a', val_obj1: 1},
{ value: 2, label: 'child_label_a', val_obj1: 1},
{ value: 3, label: 'child_label_a', val_obj1: 1}
]

can you  provide it ?..

Hello @gieboyz,
To achieve this you can change the list of options that is bound to your second ng-select if the first ng-select changes.
Use the selected output event of your first ng-select to figure out what option is selected, and based on that replace the list of options that is bound to your second ng-select.

I have also been attempting to do this, and have been running into an issue with infinite looping.  You cannot use a filter pipe on the options because it causes ng-select to infinitely re-evaluate the pipe... I will post my solution here when I figure it out.


2.0.0-pre branch mql4zmq_strerror returns garbage

I think the function is not returning unicode.

There's been no answer to this issue in almost a year, so I've put a new version up at
https://github.com/OpenTrading/OTMql4Zmq
It addresses the problem in this issue.
I'm still having trouble with it both with curruption on sending and access violations on receiving, so if you have a chance, please try it out.


[IMPROVEMENT] Use PDB to protect Longhorn components from unexpected drains

When using kubectl drain on a single node cluster there might be a case where it's impossible to correctly cleanup/detach a volume. Since the csi sidecars might end up evicted before the pod/va is cleaned up correctly.
It would be useful to have PDB on the csi-sidecars, to prevent all sidecars from being unavailable.
We could consider removing the PDB once we have evaluated that all longhorn volumes are no longer in use.
But even as a first step just adding a PDB with a minAvailablity of 1 for the csi sidecars would be beneficial.
A similiar thing would be useful for the share-manager, since it's possible that the share-manager pod gets evicted before the nfs unmount happens in the csi-plugin which might stall the kubelet/csi-plugin. in single node clusters the nfs mount would get stuck since the share-manager would no longer come up, since the node is cordoned during the drain process.

A separate idea is to look into providing a script to ignore the longhorn components/namespace as part of the drain.
Since if you drain all workloads that use the longhorn volumes on that node, there wouldn't be any active volumes left on that node.
This does not apply to replica and share-manager since they could be used by a different node in a multi node cluster.
Simliar to what kubevirt does in it's maintenace guide provide a selector that drains the appropriate components.
REF: https://kubevirt.io/user-guide/operations/node_maintenance/#evict-all-vms-from-a-node
REF: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#drain

potentially issues that are caused by this mismatch
https://github.com/longhorn/longhorn/issues/2933

I tested the label selector idea and it works well, as a current workaround, example below:
# not equal x (includes absent key)
kubectl drain --pod-selector='!longhorn.io/component' jmoody-lh-work3 --ignore-daemonsets

# not equal x and not equal y selector
kubectl drain --pod-selector='!longhorn.io/component,app!=csi-attacher,app!=csi-provisioner' jmoody-lh-work1 --ignore-daemonsets

Note from @innobead

So, I think this should be good enough for now, but probably we should also update our doc for upgrade part about the drain usage.
https://longhorn.io/docs/1.2.2/volumes-and-nodes/maintenance/#updating-the-node-os-or-container-runtime

@PhanLe1010 has done the doc, lowering the priority and removing this from the sprint.

Just leaving this note here for future reference.
If someone wants to do a shutdown of all volumes without having to modify the scale of the end user/application deployments in the cluster. As well as a zero rebuild maintenance.
How useful this is depends on the situation :)

they can cordon each node first
then run the below drain command on each node this will ignore all the instance-managers + webhooks
this will only evict the workloads since each node is cordoned, the scheduler will be unable to place the workloads on any other node and therefore all volumes will be shutdown cleanly and all engine/replica processes will be shutdown cleanly.

kubectl drain --pod-selector='app!=csi-attacher,app!=csi-provisioner,longhorn.io/component!=instance-manager,app!=longhorn-admission-webhook,app!=longhorn-conversion-webhook' <node> --ignore-daemonsets

Just leaving this note here for future reference. If someone wants to do a shutdown of all volumes without having to modify the scale of the end user/application deployments in the cluster. As well as a zero rebuild maintenance.
How useful this is depends on the situation :)
* they can cordon each node first

* then run the below drain command on each node this will ignore all the instance-managers + webhooks

* this will only evict the workloads since each node is cordoned, the scheduler will be unable to place the workloads on any other node and therefore all volumes will be shutdown cleanly and all engine/replica processes will be shutdown cleanly.

kubectl drain --pod-selector='app!=csi-attacher,app!=csi-provisioner,longhorn.io/component!=instance-manager,app!=longhorn-admission-webhook,app!=longhorn-conversion-webhook' <node> --ignore-daemonsets

Josh, as we discussed today on the GSK call, if we cordon all nodes, then drain and uncordon each node in turn with the above command...
That will not get rid of old versions of instance managers if they have replicas on another node, correct?
So we may have to cordon, then drain ALL nodes before uncordoning again, correct?

Assuming that the goal is get rid of old versions of instance managers, I have tested the following steps:

Stop the automatic engine upgrade
Cordon all nodes
For each node:

drain by the command kubectl drain --pod-selector='app!=csi-attacher,app!=csi-provisioner,[longhorn.io/component!=instance-manager,app!=longhorn-admission-webhook,app!=longhorn-conversion-webhook](http://longhorn.io/component!=instance-manager,app!=longhorn-admission-webhook,app!=longhorn-conversion-webhook)' <node> --ignore-daemonsets
uncordon the node
wait for the workload of this node to fully comeback
cordon this node again
move to next node

Wait until all old instance managers are removed by Longhorn
Uncordon all nodes
Enable the automatic engine upgrade

@PhanLe1010 just noticed the doc has not updated with the latest excluded pod selector including webhook. Please help with that update. Thanks.

The goal is to prevent the volume-lifecycle managed pods from being drained by the drain operation, so basically having PDBs to protect the longhorn webhooks, CSI sidecars, and CSI deployer while there are volume engines still running on the node.
After all running volumes are evicted on the draining node, can delete those PBDs to make the drain operation continue. @PhanLe1010 WDYT?

Test Plan
1 Basic unit tests
1.1 Single node cluster

Deploy Longhorn
Verify that there is no PDB for csi-attacher, csi-provisioner, longhorn-admission-webhook, and longhorn-conversion-webhook
Manually create a PVC (simulate the volume which has never been attached scenario)
Verify that there is no PDB for csi-attacher, csi-provisioner, longhorn-admission-webhook, and longhorn-conversion-webhook because there is no active workload yet
Create a deployment that uses one RW0 Longhorn volume.
Create another deployment that uses one RWO Longhorn volume. Scale down this deployment so that the volume is detached
Drain the node by kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force
Observe that the workload pods are evited first -> PDB of csi-attacher, csi-provisioner, longhorn-admission-webhook, and longhorn-conversion-webhook are removed -> csi-attacher, csi-provisioner, longhorn-admission-webhook, and longhorn-conversion-webhook, and instance-manager-e pods are evicted
Observe that instance-manager-r is NOT evicted. In the current design, if the node contains the only healthy replica of the volume, the instance-manager-r cannot be evicted. This issue will be addressed at the ticket https://github.com/longhorn/longhorn/issues/5549

After updating the doc including node maintenance and Kubernetes upgrade (we don't have this yet, so probably can create a specific page for it, but overall it's similar to node maintenance or we would like to combine them together), let's move this to ready-for-testing.

@khushboo-rancher @yangchiu let's add test cases as part of Rancher integration testing.
cc @longhorn/qa

Test cases https://github.com/longhorn/longhorn-tests/pull/1295 covers this improvement testing.

Verified passed on master-head (longhorn-manager 79acd76) by the test plan. Drain and upgrade operations in each test case work as expected.


Withdraw to for Collateral and Loans

In case of no collateral exist on the origin chain user must be able to withdraw to other chains.

this will be batched with the loans liquidation work


Update Alexandria message API for custom payload encoding

What was wrong?
We need the ability to customize how message payloads are encoded to support the message format of the Advertise message that is being introduced in #186
How was it fixed?
These is now a get_payload_for_encoding() API on the AlexandriaMessage class which allows for custom handling of payload encoding.
Cute Animal Picture

@marcgarreau @lithp merging as this one shouldn't be overly controversial.  See #186 for how this actually gets used...


Failed to download SyncDuties while connected to lighthouse or teku beacon node

The following was tested on Goerli (before the merge):
While connecting the lodestar validator to a lighthouse or teku beacon node I receive the following error:
Aug-01 21:22:01.648[] error: Failed to download SyncDuties epoch=111669 JSON expected key dependent_root is undefined - Failed to obtain SyncDuties
    Error: JSON expected key dependent_root is undefined - Failed to obtain SyncDuties
    at ContainerType.fromJson (/usr/app/node_modules/@chainsafe/ssz/src/type/container.ts:340:15)
    at Object.request [as getSyncCommitteeDuties] (file:///usr/app/node_modules/@lodestar/api/src/utils/client/client.ts:77:27)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at SyncCommitteeDutiesService.pollSyncCommitteesForEpoch (file:///usr/app/node_modules/@lodestar/validator/src/services/syncCommitteeDuties.ts:234:24)
    at SyncCommitteeDutiesService.pollSyncCommittees (file:///usr/app/node_modules/@lodestar/validator/src/services/syncCommitteeDuties.ts:179:7)
    at async Promise.all (index 1)
    at SyncCommitteeDutiesService.runDutiesTasks (file:///usr/app/node_modules/@lodestar/validator/src/services/syncCommitteeDuties.ts:141:5)
    at Clock.runAtMostEvery (file:///usr/app/node_modules/@lodestar/validator/src/util/clock.ts:96:7)

The validator still produces attestations but I don't know if it produces blocks.
lodestar version: 0.41.0
teku version: 22.8.0
ligththouse version: 2.5.1
For reference: I'm trying to keep track of most client combinations here: https://github.com/TobiWo/ethereum-consensus-client-cross-connectivity

That's an awesome initiative, thank you so much testing interop.

@TobiWo If you need to use an image of Lodestar with this fix, please pull chainsafe/lodestar:next


Don't close on minimize

This fixes part of https://github.com/Jigsaw-Code/outline-client/issues/860.
Currently when you minimize, the window is closed. That's clearly not the user intent, who could click on 'close' instead.
The issue is exacerbated on Linux, where the tray click is broken because of https://github.com/electron/electron/issues/14941

Superseded by https://github.com/Jigsaw-Code/outline-client/pull/972


Run R in Fedora 40 with Rosetta

Describe the bug
Starting R with a simple expression hangs with Rosetta.
To Reproduce
docker run --rm -ti ghcr.io/r-hub/containers/gcc14:latest R -q -e TRUE

Expected behavior
Output:
> TRUE
[1] TRUE
>
>

Diagnostic report (REQUIRED)
OrbStack info:
Version: 1.6.1
Commit: bfaddc6839de8b00b7aff767dbd673ac6ad4259e (v1.6.1)
System info:
macOS: 14.4.1 (23E224)
CPU: arm64, 8 cores
CPU model: Apple M3
Model: Mac15,12
Memory: 24 GiB
Full report: https://orbstack.dev/_admin/diag/orbstack-diagreport_2024-06-05T22-03-40.383327Z.zip

Screenshots and additional context (optional)
No response

Duplicate of #530

Thanks. The issue you pointed to seems to suggest that the problem can be solved by compiling R without using AVX? Can you please confirm?

It looks like AVX is the problem, so it should unless there are more unsupported instructions.


feat: add the ActNotify to the list of allowed seccomp actions

What type of PR is this?

/kind feature
What this PR does / why we need it:
Add the ActNotify to the list of allowed seccomp actions. This has required to update the github.com/containers/common to latest version in order to get this change https://github.com/containers/common/pull/1027.
Which issue(s) this PR fixes:

Does this PR have test?

Special notes for your reviewer:
Does this PR introduce a user-facing change?

Add SCMP_ACT_NOTIFY to the list of allowed seccomp actions

/ok-to-test
Great contribution to c/common, thank you!

Codecov Report

Merging #929 (d528b8d) into main (7c2e895) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #929   +/-   ##
=======================================
  Coverage   50.73%   50.73%
=======================================
  Files          42       42
  Lines        4766     4766
=======================================
  Hits         2418     2418
  Misses       2262     2262
  Partials       86       86

/retest

/test all

/test all

/test all

/retest

/test all

/test all

/retest

/test all

/test all

/test all

@saschagrunert Please could you add again the lgtm label? All tests are green now. Thanks!


Release 0.52.4

The targeted release date is the end of January 2023.

This was released "early" to get a high priority fix out.


Layer violations in Structure101

In the process of testing our plugin/flavour for Structure101/g which parses JS/TS projects, we identified a few problems with the layering in VSCode 08b92738094. In a private channel, @egamma asked us to enter this issue.
Steps to Reproduce:

Install Structure 101/g Studio
Install the flavour/plugin net.betterdeveloper.javascript.imports 1.1.2
Get the VSCode commit hash 08b92738094 (to make sure it is the same src I looked at)
File->New, choose the right flavour/plugin above, and run pointing at the VS Code src dir and the tsconfig file, like this:

When the conversion finishes, you will get some layer violations:

platform is using editor. "/platform/browser/contextScopedHistoryWidget.ts	imports	/editor/contrib/suggest/suggest.ts". This violation was reported in private and issue #140856 was entered by @egamma

bootstrap-amp.js uses "vs" and vice-versa:

bootstrap-amd.js	imports	vs/base/common/performance.js
bootstrap-amd.js	imports	vs/loader.js

vs/editor/test/common/model/benchmark/bootstrap.js	imports	bootstrap-amd.js
vs/server/cli.js	imports	bootstrap-amd.js
vs/server/main.js	imports	bootstrap-amd.js

base uses platform: (although that seems due to the fact that test code is stored in the same folder as production code. We will send another analysis with synthetic model transformation to emulate tests in a separate dir tree)

/base/parts/ipc/test/node/ipc.net.test.ts	imports	/platform/product/common/product.ts
/base/test/parts/quickinput/browser/quickinput.test.ts	imports	/platform/list/browser/listService.ts

I will enable/explain Model Transformations and enter a separate comment for that mode (extracting tests out into a separate structure).

In an attempt to simulate tests being separate from production code and see if production code uses test code or not, I made use of Model Transformations in Structure101:

  <transformations>
    <transformation in="*/test/*" out="[test]/{1}/test/{2}" />
    <transformation in="*/testing/*" out="[test]/{1}/testing/{2}" />
    <transformation in="*/*Testing.ts" out="[test]/{1}/{2}Testing.ts" />
    <transformation in="*/*.test.ts" out="[test]/{1}/{2}.test.ts" />
    <transformation in="*/*.integrationTest.ts" out="[test]/{1}/{2}.integrationTest.ts" />
    <transformation in="*/workbenchTestServices.ts" out="[test]/{1}/workbenchTestServices.ts" />
  </transformations>

The need for many rules comes from the multiple naming conventions present in the code.
There are cycles from vs into test even with the transformations above:

vs/workbench/api/browser/extensionHost.contribution.ts	imports	[test]/vs/workbench/api/browser/mainThreadTesting.ts
vs/workbench/api/common/extHost.api.impl.ts	imports	[test]/vs/workbench/api/common/extHostTesting.ts
vs/workbench/api/common/extHost.protocol.ts	imports	[test]/vs/workbench/contrib/testing/common/testCollection.ts
vs/workbench/api/common/extHostTestingPrivateApi.ts	imports	[test]/vs/workbench/contrib/testing/common/testId.ts
vs/workbench/api/common/extHostTypeConverters.ts	imports	[test]/vs/workbench/contrib/testing/common/testCollection.ts
vs/workbench/api/common/extHostTypeConverters.ts	imports	[test]/vs/workbench/contrib/testing/common/testId.ts
vs/workbench/contrib/snippets/browser/snippetsService.ts	imports	[test]/vs/editor/test/common/modes/testLanguageConfigurationService.ts
vs/workbench/workbench.common.main.ts	imports	[test]/vs/workbench/contrib/testing/browser/testing.contribution.ts

Do we want to have sub-layering inside platform?  Note that in platform there is also a small tangle between diagnostics and launch:

/launch/electron-main/launchMainService.ts	imports	/diagnostics/common/diagnostics.ts

and a much bigger tangle:

Workbench also shows a tangle:

On @sglebs's prompting I took a look at the code in S101 Studio. I notice that the workbench folder contains an underlying file tangle of 749 files. I think you'd need to break that up a bit in order to layerize the workbench sub-folders. Removing just a couple of outgoing dependencies from workbench.web.main.ts would (if appropriate) break the big file tangle into much smaller ones (max 42 classes), which should make restructuring to a layered structure much easier.
I'd be happy to contribute if this is important to the team - let me know.

Some feedback:

contrib/testing is not a violation if you think this is test code. that is actually enabling the testing functionality in VSCode
it is expected that workbench.web.api.ts depends on "everything" because this is the main entry file for VSCode for web
I think we can exclude the bootstrapping JS files from layer breaks
I think we do not have to look at dependencies from tests

Regarding test code: IMHO tests should sit on top of code that enables testing, but not the other way around. In my second comment above I have used model transformations to simulate tests being in a separate root "namespace"  ( you will notice that I added a synthetic /[test] folder/package at the top). It may be worth tweaking the rules I used, maybe I moved too much into /[test] (I would need a deeper knowledge of the codebase at this point). Anyway, here are the rules I used to move test code to an upper layer "/[test]":
  <transformations>
    <transformation in="*/test/*" out="[test]/{1}/test/{2}" />
    <transformation in="*/testing/*" out="[test]/{1}/testing/{2}" />
    <transformation in="*/*Testing.ts" out="[test]/{1}/{2}Testing.ts" />
    <transformation in="*/*.test.ts" out="[test]/{1}/{2}.test.ts" />
    <transformation in="*/*.integrationTest.ts" out="[test]/{1}/{2}.integrationTest.ts" />
    <transformation in="*/workbenchTestServices.ts" out="[test]/{1}/workbenchTestServices.ts" />
    <transformation in="*/extHostTestingPrivateApi.ts" out="[test]/{1}/extHostTestingPrivateApi.ts" />
  </transformations>

and here are the violations that remain according to the above logical layering:
vs/workbench/api/browser/extensionHost.contribution.ts	imports	[test]/vs/workbench/api/browser/mainThreadTesting.ts
vs/workbench/api/common/extHost.api.impl.ts	imports	[test]/vs/workbench/api/common/extHostTesting.ts
vs/workbench/api/common/extHost.protocol.ts	imports	[test]/vs/workbench/contrib/testing/common/testCollection.ts
vs/workbench/api/common/extHostCommands.ts	imports	[test]/vs/workbench/api/common/extHostTestingPrivateApi.ts
vs/workbench/api/common/extHostTypeConverters.ts	imports	[test]/vs/workbench/api/common/extHostTestingPrivateApi.ts
vs/workbench/api/common/extHostTypeConverters.ts	imports	[test]/vs/workbench/contrib/testing/common/testCollection.ts
vs/workbench/api/common/extHostTypeConverters.ts	imports	[test]/vs/workbench/contrib/testing/common/testId.ts
vs/workbench/contrib/snippets/browser/snippetsService.ts	imports	[test]/vs/editor/test/common/modes/testLanguageConfigurationService.ts
vs/workbench/workbench.common.main.ts	imports	[test]/vs/workbench/contrib/testing/browser/testing.contribution.ts

Probably  some entries should not have been moved to the upper layer "/[test]" in my model transformations - this can be easily changed once it is confirmed/determined by an insider engineer/architect.
Another approach is to simply skip test from the analysis. I avoid this because I have seen my fair share of production code using test code in previous lives, so I like to see a clean layer structure where "/tests" uses code underneath but not the other way around. Model transformations are great because they allow this logical view & enforcement without imposing a strict folder structure on the teams.
Congrats on the great work, let me know if I can be of any further assistance. I can easily run the analysis again, tweak the model transformations, etc. Cheers!

I'm excited to see the power of Structure101 now being harnessed for TS/JS and applied to this codebase, where architecture is held in such high regard.

I don't understand the layer violation from vs/workbench/api/common to vs/workbench/contrib/testing. It is true that vs/workbench/api/* is not very strict, i.e. can depend on pretty much everything, but I am not sure what it would bring to enforce layers for API, because API span pretty much everything we provide from core+contrib?

@bpasero it may be the case that the existing "packages"(folders) are not true components and/or layers, so circularity among them is not really a violation of the Acyclic Dependency Principle among components. In this case a logical layer containing more than one "physical" package/folder can be created as well (at least in Structure101 this is easy), so you might have circularity inside but the thing is supposed to be reused as a whole, so no big problem. Other characteristics of the layers/components should be checked (Reuse-release Equivalence Principle, etc - more details here) to decide on the proper layering. Alternatively you can create a logical layer/component with parts from separate physical folders. For example, one can create an [api] folder/package/layer as a logical thing and enforce rules for it, despite having parts spread out "physically" across folders. The possibilities are many, but I do not know how to enforce this with eslint rules.
GOTCHA: Note that bundling packages/components to form a bigger logical package may get you off the hook regarding Tangle at higher levels, but it may produce a bigger component, which increases what Structure101 calls Fat. Here is the current situation of Fat Versus Tangle in VSCode according to the analysis I did:

Trading Tangle for Fat won't get you any closer to the origin (0,0) in most cases.
Feel free to contact me privately if you want to bounce some ideas or just want to see how things are in the tool. If I can be of any help to the project, just let me know.

Thank you for the analysis!
Unfortunately I was unsuccessful in running Structure101 on our sources. On macOS, I could only find version 1.1.0 of the plugin, which after a chmod +x macos/js2s101 and some tweaks to our tsconfig.json did eventually execute, but failed with Out-Of-Memory. I switched to Windows, where I found version 1.1.3-rc-1 of the plugin, which worked out of the box, but also eventually (after about 5-10 minutes of analysis) failed with Out-Of-Memory. Are there some flags or settings that I could tweak to give it more memory? If js2s101 is using nodejs under the hood, in nodejs it is usually possible to use something like node --max_old_space_size=8192 to signal that it can consume more heap. Is there a setting that I can configure somewhere to pass that argument and overcome the Out-Of-Memory?

In parallel with this issue, prompted by https://github.com/microsoft/vscode/issues/140857, I spent some time to improve our rules and our ESLint plugin that validates our imports. I pushed those improvements via https://github.com/microsoft/vscode/commit/62b0d5cb815aa8161ffdb6550ed1787e4bffdd17 . I have also identified about 9 layer breakers, 2 of which in test files. I will create issues for each of those and cross-reference them with the findings from this thread.

Going through problems reported in this issue (using ✅  to mark problems that are tracked in other issues):

✅ platform is using editor in contextScopedHistoryWidget.ts

this is now flagged by our code import eslint plugin.
tracked in https://github.com/microsoft/vscode/issues/140856

✅ bootstrap-amd.js uses "vs" and vice-versa:

vs/editor/test/common/model/benchmark/bootstrap.js: this is a test script that can be launched via node vs/editor/test/common/model/benchmark/bootstrap.js. This will auto-generate tests for our text buffer implementation (it generates buffers and edits and execute these edits and compares with a simple non efficient text buffer implementation). I don't think I have launched this script in years and maybe we can just delete it, but it isn't a layer breaker, it is just a test utility script.
src/vs/server/cli.js, src/vs/server/main.js: these are the entry points to vscode-server. I've started a discussion about them in https://github.com/microsoft/vscode/issues/140997

✅ base uses platform

ipc.net.test.ts, quickinput.test.ts
these are now flagged by our code import eslint plugin.
tracked in https://github.com/microsoft/vscode/issues/140982
tracked in https://github.com/microsoft/vscode/issues/140983

✅ regarding tests being separate from production code:

the Model Transformations are slightly incorrect because we have a feature called testing, so */testing/* or */*Testing.ts should not be mapped to a separate [test] namespace.
a layer breaker was indeed in snippetsService.ts

https://github.com/microsoft/vscode/issues/140986

this and another occurrence is now found by our code import eslint plugin:

https://github.com/microsoft/vscode/issues/140987

❓ regarding vs/platform/diagnostics <-> vs/platform/launch

it looks like ILaunchMainService has a method called getRemoteDiagnostics that might be better to be moved to IDiagnosticsService. I'm not sure who owns this code anymore. @bpasero do you know?

❓regarding the much bigger tangle:

the tangle is very likely caused by implementations of services depending on other services. For example, we have a log service implementation which uses the file service to write to disk, or we use the log service for logging in the implementation of the environment service. Although very complex looking, I don't think this is necessarily a problem, as the service interfaces look clean. But I think there might be opportunities to split/regroup some services.

❓regarding the workbench tangle:

I think there is opportunity for improvement here.
we could aim to disallow importing workbench/api/~ in workbench/services/~. I've created https://github.com/microsoft/vscode/issues/141003 for discussion.
we could also consider merging workbench/services/~ into workbench/~.

@sglebs I'd love to get Structure101 running. Do you have any insights into how to overcome the Out-Of-Memory error that I'm running into?

@alexdima did you point s101 at the sources in vscode/src ? Or did you point it at the root dir "vscode"? You will see that my documented steps say to point at vscode/src and the tsconfig file vscode/src/tsconfig.json.
I will investigate the Out of Memory Error, perhaps pointing it at the root folder vscode (instead of vscode/src like I did).
Thanks!

@alexdima 1.1.0 does not support the tsconfig file of vscode, make sure you run 1.1.3. It should now be available there now (I think it had not been uploaded to the s101 site yet by the time you tried).
In my case I actually deleted my ~/structure101g/flavors/net.betterdeveloper.javascript.imports_1.1.0 to make sure I would not make a mistake of running it.  Version 1.1.3 supports the tsconfig format present in vscode. Also, 1.1.0 was quite slow.
Try 1.1.3 pointing at vscode/src and let me know how it goes please.

@alexdima

it looks like ILaunchMainService has a method called getRemoteDiagnostics that might be better to be moved to IDiagnosticsService. I'm not sure who owns this code anymore

I can look into that if you report an issue.

@alexdima I adjusted Model Transformation according to your insider info that "the Model Transformations are slightly incorrect because we have a feature called testing, so /testing/ or */*Testing.ts should not be mapped to a separate [test] namespace" and now I only see 2 violations there:
vs/workbench/contrib/snippets/browser/snippetsService.ts	imports	[test]/vs/editor/test/common/modes/testLanguageConfigurationService.ts
vs/workbench/contrib/testing/common/testStubs.ts	imports	[test]/vs/workbench/contrib/testing/test/common/ownedTestCollection.ts

The adjusted Model Transformation rules are:
  <transformations>
    <transformation in="*/test/*" out="[test]/{1}/test/{2}" />
    <transformation in="*/*.test.ts" out="[test]/{1}/{2}.test.ts" />
    <transformation in="*/*.integrationTest.ts" out="[test]/{1}/{2}.integrationTest.ts" />
    <transformation in="*/workbenchTestServices.ts" out="[test]/{1}/workbenchTestServices.ts" />
    <transformation in="[test]/[test]/[test]/*" out="[test]/{1}" />
    <transformation in="[test]/[test]/*" out="[test]/{1}" />
  </transformations>

(The last 2 rules are necessary for the cases where more than 1 rule is applied to the same element - a sort of clean-up at the end)

did you point s101 at the sources in vscode/src ? Or did you point it at the root dir "vscode"?

🤦 That was the problem! Sorry about that, I'm now able to run the analysis. Thank you!

@alexdima Glad to hear you got it going!  Over here, even pointing at the root folder (incorrectly) I can't cause Out of Memory. I have a 2016 MacBook Pro, 16GB RAM here (old machine by today's standards). Do you mind sharing detailed info on the hardware that caused OoM with plugin version 1.1.3 pointing at the root folder? Is it an M1 perhaps? Or maybe an even older Mac? Thanks!

@sglebs I am trying on a MacBook Pro 2019, 32GB RAM.
There must have been some unlucky timing, maybe you were releasing 1.1.3rc-1 exactly when I was trying to install it. Now, on macOS I see 1.1.3rc-1, but when I tried earlier I only saw 1.1.0, so the macOS Out-Of-Memory occurred with 1.1.0. I also pointed to vscode instead of vscode/src.
I then switched to a Windows 11 VM with 8GB, where I could see 1.1.3rc-1, but which failed to install the first few times (I think the zip was being uploaded at the same time I was trying to download/install it). Also here I pointed to vscode instead of vscode/src when the Out-Of-Memory occurred.
But after correcting and pointing to vscode/src, the analysis runs fine now for me 💯 .

@alexdima regarding your observation "the tangle is very likely caused by implementations of services depending on other services. For example, we have a log service implementation which uses the file service to write to disk, or we use the log service for logging in the implementation of the environment service." it is important to note that services using services is ok if the dependency graph is acyclic (ADP - Acyclic Dependency Principle). You will only get a tangle in the tool if A uses B and B uses A (directly or indirectly). The question to ask is: should they have these cyclic dependencies? Is this desirable? Sometimes a simple service injection at runtime for the "feedback dependency" will solve it. Or maybe the feedback dependency is not supposed to be there at all. You get the idea. (In concrete terms, I mean if the Environment Service needs the Logging Service and vice-versa, just decide who the "bottom-most" one is and inject the "above" one as a runtime dependency instead of compile-time dependency, as this will make the bottom one reusable on its own due to no tangle). Just some thoughts, I am not an expert on the inner workings of the current code. Just my 2 cents. Congrats on the work!

@alexdima FYI the plugin generates FAT and SIZE numbers for files. FAT comes from the total cyclomatic complexity of the file. Size comes from the lines of code (LOC). S101 also computes FAT for modules, and then the final FAT % shown in that nice green/orange 2D graph. You may want to have FAT under control as well.
@chedgers do you care to talk a bit about Fat as well? Share some wisdom applied here? Thanks!

"Fat" is too much complexity in one place for a developer to easily understand. The s101 standard is to use cyclomatic complexity for functions since "number of paths" is a better measure of understandablilty (than say just LoC). The same principle is used at higher levels of composition. So at the file level, we count the number of function-to-function dependencies (rather than say just the number of functions). At the folder level it's the number of file-to-file dependencies.
Containment is a kind of coupling, so a Fat file can be dependent on/from an excessive number of other files - compared to if it was split into several simpler files, each with a fewer dependencies. In this way excessive Fat makes a codebase harder to restructure (to e.g. remove tangles, fix layering). Often splitting a Fat file is a useful precursor to resolving layering problems. The reduced granularity of dependency making it easier to relocate a subset of files/functions and remove feedback between folders... Limiting Fat as the code develops keeps the codebase more understandable and flexible.
Actually given the JS/TS flavor stops at the file level, I was pleasantly surprised to see a measure of Fat for that @sglebs - I presume that's the sum of the CC for all functions in the file?

That is correct, @chedgers . The plugin generates Fat for a file as being the sum of the CC for all code in the file. It also generates the Size property as being total LOC of the file.

Is there a way to configure certain layers to be the same layer? These two:

src/vs/workbench
src/vs/workbench/services

Are a somewhat expected tangle and it is probably unrealistic to untangle it but it makes it harder to see other tangles.

That's what transformations do. It might work if you map vs/workbench/services/* onto vs/workbench (via Project > Tranformations)

Yes transformations is a good way to do that. You could also use "actions" to do the same thing... right-click/unwrap on the services folder would have the same effect on the model as @jrieken's xform suggestion. Or you could delete (right-click/cut) the dependencies themselves to remove them from the model. Any such "actions" are added to the current Action List and are re-applied any time you load the model (if that Action List is selected).

I am curious: was our JS/TS plugin for Structure101 useful after all? Have the tangles been mastered/eliminated?  Were the ESLint rules patched to be more robust? I ended up mentioning this incident at https://www.linkedin.com/pulse/javascripttypescript-code-does-have-mess-marcio-marchini/


Want to use Pylint for python3..

Is pylint supported ?

Not yet, but if someone wants to open a pull request for it which works, I'll take that. If nobody else adds it, I'll add it eventually.

Pylint has a bit of a ...difficult output format. Even when you manually make it something gcc-like, it likes to spit out multiline output with arrow pointers not unlike clang. We can't just drop those lines because the actual explanation is included there. I'll see what I can do, but it might be a while.

One of the linters, I can't remember which one, handles that kind of output by looking for the markers every other line.

The thing with pylint is it is only one some errors, not all of them. And the error message is split over the two lines, so we need to parse that and strip the arrow. It's... bleh...

I've opened a PR for pylint support here https://github.com/w0rp/ale/pull/151

Great..

This is now is master!


chore(main): release 2.4.1

:robot: I have created a release beep boop
2.4.1 (2024-11-12)
Features

moved pkg out of monorepo + minor improvements (16ebb5d)

Miscellaneous Chores

release 2.4.1 (1794c06)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/nico-i/eslint-config/releases/tag/v2.4.1 :sunflower:


rules: add substring feature

closes #737

once you merge this, then merge:

https://github.com/fireeye/capa-rules/pull/449
https://github.com/fireeye/capa-rules/pull/451


firebase

can you help in config firebase place

Hi
في السبت، ٤ مايو ٢٠٢٤، ٩:٥٧ م Mohamed @.***> كتب:

can you help in config firebase place
—
Reply to this email directly, view it on GitHub
https://github.com/dc-exe/Health_and_Doctor_Appointment/issues/9, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AYCMJMZ3QKAF6L4QVB7GANLZAUVQVAVCNFSM6AAAAABHHBIFD6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3TSMJVGU4TGMY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Unable to bind  from init.vim

my init.vim looks like this
if exists('g:vscode')
  noremap <C-h> :call VSCodeNotify("workbench.action.navigateLeft")<CR>
  noremap <C-l> :call VSCodeNotify("workbench.action.navigateRight")<CR>
  noremap <C-k> :call VSCodeNotify("workbench.action.navigateUp")<CR>
  noremap <C-j> :call VSCodeNotify("workbench.action.navigateDown")<CR>
else
...

The thing I want to do is to use <C-h/j/k/l> to navigate windows in vscode. All the binding works except for <C-k> . I get this message from vscode instead

What have I done wrong? Or should I just unbind all the ctrl+k bindings from vscode? Thanks.

VSCode uses ctrl-k for a ton of default keybindings, which is why it's not possible to remap. This is because even if the C-k were sent to neovim (which it isn't), vscode would be waiting to know for sure that you didn't mean to use one of the default chorded bindings (like C-k C-s to open keybindings). The only solution is to unmap all vscode default bindings, which would be tedious.
However, like Josh said, you don't need to send it to neovim, you can bind it directly in VSCode. The problem would still be there though. A solution might be to use Alt or a different letter.


update dsu fabric wallet to accept also subdomains

This pull request updated front end: adds a new "subdomain" field when generating an identifier as company.

@andrejstas Hi merged - please add a subtask in the https://github.com/PharmaLedger-IMI/epi-workspace/projects/5


Add team member list

Details

This PR is related to: Issue #
Does it close the issue?:

Summary:

Note:

This PR is invalid because:

It does not follow contributing guidelines

I'll be closing it now