Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Release #944

Merged
merged 41 commits into from
Jan 14, 2025
Merged

New Release #944

merged 41 commits into from
Jan 14, 2025

Conversation

alcarney
Copy link
Member

No description provided.

alcarney and others added 30 commits October 21, 2024 21:13
pygls in `v2.0a2` switched from using the low-level asyncio APIs to
using the high-level one and surprisingly, this broke `esbonio`.

The server would start ok, but wouldn't launch Sphinx processes, the
preview command did nothing, it wouldn't even produce any log
messages! That is, until the user changed a configuration setting.

After changing a setting - any setting, the server suddenly springs
into life, logs, previews, sphinx processes all of them would start
working as if nothing was wrong.

I eventually managed to figure out that the callbacks registered by
the configuration system on the server's `ready` future were never
being called.

```
self.server.ready.add_done_callback(self._notify_subscriptions)
```

By why would changing the asyncio API in use break these callbacks?!
After spending some time with the debugger I eventually spotted the culprit

```
>>> asyncio.get_running_loop()
<_UnixSelectorEventLoop running=True closed=False debug=False>

>>> self.server.ready._loop
<_UnixSelectorEventLoop running=False closed=False debug=False>
```

The server's `ready` future was using a different event loop and
because the event loop is not running, when the future is resolved,
the callbacks were never scheduled!

While I cannot explain why this was not an issue before, I can explain
why it is an issue now.

The `ready` future is created in the constructor of the
`EsbonioLanguageServer` class - before any event loop has been created
and so it uses a new one based on the current event loop policy[1][2].

Unfortunately, when pygls later starts its main loop by calling
`asyncio.run()` it creates a new event loop, orphaning the `ready`
future in its unused event loop[3]

Since we don't need to use the `ready` future asynchronously, the
simplest fix is to convert it to future from the `concurrent.futures`
module, removing the need for an event loop completely.

[1]: https://github.com/python/cpython/blob/307c63358681d669ae39e5ecd814bded4a93443a/Lib/asyncio/futures.py#L79
[2]: https://github.com/python/cpython/blob/307c63358681d669ae39e5ecd814bded4a93443a/Lib/asyncio/events.py#L791
[3]: https://github.com/python/cpython/blob/307c63358681d669ae39e5ecd814bded4a93443a/Lib/asyncio/runners.py#L146
- Use new `pygls.io_` infrastructure
- Use new `websockets.asyncio` API
Bumps [tomli](https://github.com/hukkin/tomli) from 2.0.2 to 2.2.1.
- [Changelog](https://github.com/hukkin/tomli/blob/master/CHANGELOG.md)
- [Commits](hukkin/tomli@2.0.2...2.2.1)

---
updated-dependencies:
- dependency-name: tomli
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Bumps [typescript](https://github.com/microsoft/TypeScript) from 5.6.2 to 5.7.2.
- [Release notes](https://github.com/microsoft/TypeScript/releases)
- [Changelog](https://github.com/microsoft/TypeScript/blob/main/azure-pipelines.release.yml)
- [Commits](microsoft/TypeScript@v5.6.2...v5.7.2)

---
updated-dependencies:
- dependency-name: typescript
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Bumps [@vscode/vsce](https://github.com/Microsoft/vsce) from 3.1.1 to 3.2.1.
- [Release notes](https://github.com/Microsoft/vsce/releases)
- [Commits](microsoft/vscode-vsce@v3.1.1...v3.2.1)

---
updated-dependencies:
- dependency-name: "@vscode/vsce"
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Bumps [ovsx](https://github.com/eclipse/openvsx/tree/HEAD/cli) from 0.9.5 to 0.10.1.
- [Release notes](https://github.com/eclipse/openvsx/releases)
- [Changelog](https://github.com/eclipse/openvsx/blob/master/cli/CHANGELOG.md)
- [Commits](https://github.com/eclipse/openvsx/commits/HEAD/cli)

---
updated-dependencies:
- dependency-name: ovsx
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Using the `PerformanceNavigationTiming` interface it's possible to
determine if the page load happened due to a refresh after a build or
if we are visiting the page for the first time.
alcarney and others added 11 commits January 13, 2025 23:32
This also adds the Sphinx-side types needed to specify argument providers
and `.. highlight::` and `.. source-code::`
and other file related directives
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.24.0 to 0.24.2.
- [Release notes](https://github.com/evanw/esbuild/releases)
- [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md)
- [Commits](evanw/esbuild@v0.24.0...v0.24.2)

---
updated-dependencies:
- dependency-name: esbuild
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
updates:
- [github.com/astral-sh/ruff-pre-commit: v0.6.9 → v0.8.6](astral-sh/ruff-pre-commit@v0.6.9...v0.8.6)
- [github.com/pre-commit/mirrors-mypy: v1.11.2 → v1.14.1](pre-commit/mirrors-mypy@v1.11.2...v1.14.1)
@alcarney alcarney closed this Jan 14, 2025
@alcarney alcarney reopened this Jan 14, 2025
@alcarney alcarney merged commit 0157973 into release Jan 14, 2025
13 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants