-
-
Notifications
You must be signed in to change notification settings - Fork 104
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
Progress not functional because kind
is missing
#231
Comments
8 tasks
Thanks @dimbleby the suggestion from #198 (comment) would also solve the issue. |
8 tasks
tombh
added a commit
that referenced
this issue
May 31, 2022
This addresses #217 and #231. I am still new to the project, so I may not have the full story. But it started with a somewhat far-reaching merge to remove defaults from all serialisable fields in the API: #198. This had the knock-on effect of regressing progress notifications, as reported by @MatejKastak in #217. One of their suggestions is to not use `exclude_unset=True`. Some months later @dimbleby suggested that `exclude_none=True` would also fix the issue[1]. Considering those 2 suggestions, let's replace `exclude_unset=True` with `exclude_none=True`. 1. #198 (comment)
8 tasks
tombh
added a commit
that referenced
this issue
May 31, 2022
This addresses #217 and #231. I am still new to the project, so I may not have the full story. But it started with a somewhat far-reaching merge to remove defaults from all serialisable fields in the API: #198. This had the knock-on effect of regressing progress notifications, as reported by @MatejKastak in #217. One of their suggestions is to not use `exclude_unset=True`. Some months later @dimbleby suggested that `exclude_none=True` would also fix the issue[1]. Considering those 2 suggestions, let's replace `exclude_unset=True` with `exclude_none=True`. 1. #198 (comment)
tombh
added a commit
that referenced
this issue
May 31, 2022
This addresses #217 and #231. I am still new to the project, so I may not have the full story. But it started with a somewhat far-reaching merge to remove defaults from all serialisable fields in the API: #198. This had the knock-on effect of regressing progress notifications, as reported by @MatejKastak in #217. One of their suggestions is to not use `exclude_unset=True`. Some months later @dimbleby suggested that `exclude_none=True` would also fix the issue[1]. Considering those 2 suggestions, let's replace `exclude_unset=True` with `exclude_none=True`. 1. #198 (comment)
tombh
added a commit
that referenced
this issue
Jun 1, 2022
Fixes #217, #231. I am still new to the project, so I may not have the full story. But it started with a somewhat far-reaching merge to remove defaults from all serialisable fields in the API: #198. This had the knock-on effect of regressing progress notifications, as reported by @MatejKastak in #217. One of their suggestions is to not use `exclude_unset=True`. Some months later @dimbleby suggested that `exclude_none=True` would also fix the issue[1]. Considering those 2 suggestions, let's replace `exclude_unset=True` with `exclude_none=True`. 1. #198 (comment)
tombh
added a commit
that referenced
this issue
Jun 1, 2022
Fixes #217, #231. I am still new to the project, so I may not have the full story. But it started with a somewhat far-reaching merge to remove defaults from all serialisable fields in the API: #198. This had the knock-on effect of regressing progress notifications, as reported by @MatejKastak in #217. One of their suggestions is to not use `exclude_unset=True`. Some months later @dimbleby suggested that `exclude_none=True` would also fix the issue[1]. Considering those 2 suggestions, let's replace `exclude_unset=True` with `exclude_none=True`. 1. #198 (comment)
tombh
added a commit
that referenced
this issue
Jun 1, 2022
Fixes #217, #231. I am still new to the project, so I may not have the full story. But it started with a somewhat far-reaching merge to remove defaults from all serialisable fields in the API: #198. This had the knock-on effect of regressing progress notifications, as reported by @MatejKastak in #217. One of their suggestions is to not use `exclude_unset=True`. Some months later @dimbleby suggested that `exclude_none=True` would also fix the issue[1]. Considering those 2 suggestions, let's replace `exclude_unset=True` with `exclude_none=True`. 1. #198 (comment)
tombh
added a commit
that referenced
this issue
Jun 1, 2022
Fixes #217, #231. I am still new to the project, so I may not have the full story. But it started with a somewhat far-reaching merge to remove defaults from all serialisable fields in the API: #198. This had the knock-on effect of regressing progress notifications, as reported by @MatejKastak in #217. One of their suggestions is to not use `exclude_unset=True`. Some months later @dimbleby suggested that `exclude_none=True` would also fix the issue[1]. Considering those 2 suggestions, let's replace `exclude_unset=True` with `exclude_none=True`. 1. #198 (comment)
Fixed in #236 |
alcarney
added a commit
to alcarney/pygls
that referenced
this issue
Jul 4, 2022
This undoes the change in openlawlibrary#236 as well as bring back the explicit setting of non `None` default fields as suggested in [1] This commit also introduces serialization test cases that hopefully cover all the scenarios raised in openlawlibrary#245, openlawlibrary#231 and openlawlibrary#198 [1]: openlawlibrary#245 (comment)
8 tasks
alcarney
added a commit
to alcarney/pygls
that referenced
this issue
Jul 4, 2022
This undoes the change in openlawlibrary#236 as well as bring back the explicit setting of non `None` default fields as suggested in [1] This commit also introduces serialization test cases that hopefully cover all the scenarios raised in openlawlibrary#245, openlawlibrary#231 and openlawlibrary#198 [1]: openlawlibrary#245 (comment)
alcarney
added a commit
to alcarney/pygls
that referenced
this issue
Jul 4, 2022
This undoes the change in openlawlibrary#236 as well as bring back the explicit setting of non `None` default fields as suggested in [1] This commit also introduces serialization test cases that hopefully cover all the scenarios raised in openlawlibrary#245, openlawlibrary#231 and openlawlibrary#198 [1]: openlawlibrary#245 (comment)
tombh
pushed a commit
that referenced
this issue
Jul 4, 2022
This undoes the change in #236 as well as bring back the explicit setting of non `None` default fields as suggested in [1] This commit also introduces serialization test cases that hopefully cover all the scenarios raised in #245, #231 and #198 [1]: #245 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The classes used for progress API all have a
kind
property which is used in the LSP protocol so that the client knows if it's a begin, progress or end message:pygls/pygls/lsp/types/basic_structures.py
Lines 442 to 459 in 4772250
When these classes are used, usually the
kind
attribute is not set in the constructor, as we can see in the json example, it is:pygls/examples/json-extension/server/server.py
Line 205 in 4772250
and the kind is not passed explicitly like that:
Because it is default value of the model, it's not needed to specify the kind and this is more elegant to not pass the kind.
The whole progress example stopped working after b84098c , more specifically this chunk which removes this code:
pygls/pygls/lsp/types/basic_structures.py
Lines 57 to 63 in ee17487
This block was responsible for serialising the
kind
attributes that are set as default values.As we can see in log file, this message is serialised without kind.
If we add back the
__init__
method, thenkind
is properly serialised and the progress example works.PS: very few of the protocol classes are using default values like this, maybe there is only the ones used for progress and also
CreateFile
DeleteFile
andDeleteFile
.PPS: an easy workaround is to specify the
kind
explicitlyThe text was updated successfully, but these errors were encountered: