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

Progress not functional because kind is missing #231

Closed
perrinjerome opened this issue Apr 3, 2022 · 3 comments
Closed

Progress not functional because kind is missing #231

perrinjerome opened this issue Apr 3, 2022 · 3 comments

Comments

@perrinjerome
Copy link
Contributor

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:

class WorkDoneProgressBegin(Model):
kind: str = 'begin'
title: str
cancellable: Optional[bool]
message: Optional[str]
percentage: Optional[NumType]
class WorkDoneProgressReport(Model):
kind: str = 'report'
cancellable: Optional[bool]
message: Optional[str]
percentage: Optional[NumType]
class WorkDoneProgressEnd(Model):
kind: str = 'end'
message: Optional[str]

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:

ls.progress.begin(token, WorkDoneProgressBegin(title='Indexing', percentage=0))

and the kind is not passed explicitly like that:

    ls.progress.begin(token, WorkDoneProgressBegin(title='Indexing', percentage=0,         kind='begin'))

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:

def __init__(self, **data: Any) -> None:
super().__init__(**data)
# Serialize (.json()) fields that has default value which is not None
for name, field in self.__fields__.items():
if getattr(field, 'default', None) is not None:
self.__fields_set__.add(name)

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.

INFO:pygls.protocol:Sending data: {"jsonrpc": "2.0", "method": "$/progress", "params": {"token": "6f82fd14-87e4-403c-9c33-0cdc92c54cbd", "value": {"title": "Indexing", "percentage": 0}}}

If we add back the __init__ method, then kind 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 and DeleteFile.

PPS: an easy workaround is to specify the kind explicitly

@dimbleby
Copy link
Contributor

dimbleby commented Apr 3, 2022

#198 (comment)

@perrinjerome
Copy link
Contributor Author

Thanks @dimbleby the suggestion from #198 (comment) would also solve the issue.

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 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)
@tombh
Copy link
Collaborator

tombh commented Jun 2, 2022

Fixed in #236

@tombh tombh closed this as completed Jun 2, 2022
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)
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants