haskell / haskell/lsp

Automatically downgrade responses in order to match client capabilities

Open
#367 1 comment 1 reaction 0 assignees View on GitHub
Dominant language
Haskell
Stars
423
Forks
105
PR merge metrics
No merged PRs in 30d

Description

Many specification features take the form of optional additional fields on responses. This means that so long as clients ignore fields they don't recognize or handle, servers can be fairly lax about checking the client capabilities when they return responses.

However:
1. Sometimes you can't do this at all. An `InsertReplaceTextEdit` is not a subclass of a `TextEdit`, so a client that doesn't support `InsertReplaceTextEdit`s will probably just fail if you send it one.
2. Sometimes you lose information this way. If you have populated the `labelDetails` field for a `CompletionItem`, you might lose useful information for the user if it is just dropped, which otherwise you might have put into the `label`.
3. It's just a bit ugly to send stuff that the client doesn't understand, and we it's not easy to notice this (previously: https://github.com/haskell/lsp/issues/306).

But doing better currently relies a lot of discipline to check the client capabilities everywhere and have lots of branching logic.

So here's an idea: provide a way to automatically _downgrade_ a response to match the client capabilities. In many cases this will be trivial: drop the unsupported fields. But in other cases we can do a translation that does its best to carry on as much information as possible: turn an `InsertReplaceTextEdit` into a `TextEdit` by taking the insertion edit; drop `labelDetails` by adding it to the `label`, etc. And if we can't do anything we can perhaps emit a warning.

Take that, stick it in a typeclass, and then we can give people a generic downgrader that they can stick onto the end of their handlers to ensure they get appropriate output.

Contributor guide

Open the contributing guide

Research direction

The issue names no specific files, tests, or entry points; start by locating the response types and client-capability handling in the Haskell library. Define the scope of a generic downgrader, including unsupported fields, translations such as InsertReplaceTextEdit to TextEdit, and warnings when no conversion is possible.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.