Inappropriately supplying `documentChanges` during code action resolution

I'm working on Code Action support for an upcoming BBEdit feature update, and a beta tester found a bug, as follows:

When BBEdit sends a textDocument/codeAction request to the server, it's responding with workspace edits, even though the client did not ever advertise support for same — and in fact even if the client explicitly reports that it does not support workspace edits.

For example, in response to this request:

document:file:///Users/ben/Code/ghg/app/models/company_data_snapshot.py
parameters: {
    context =    {
        diagnostics =        (
        );
    };
    range =    {
        end =        {
            character = 0;
            line = 18;
        };
        start =        {
            character = 0;
            line = 17;
        };
    };
}

The server responds with:

2022-05-04 12:36:36.318: Response to sync request textDocument/codeAction: (
    {
        edit =
        {
            documentChanges =
            (
                {
                    textDocument = { uri: "file:///Users/ben/Code/ghg/app/models/company_data_snapshot.py" }
                    edits = (omitted for brevity)
                }
            )
        }
    }
)

This would be correct if BBEdit had advertised that it implements workspace edits (workspace.workspaceEdit), but it does not advertise that at all, in which case Jedi should have supplied something like:

{
    edit =
    {
        changes =
        (
            {
                "file:///Users/ben/Code/ghg/app/models/company_data_snapshot.py":
                    (...edits omitted for brevity...)
            }
        )
    }
}

I think I have a functioning workaround, but it would be more compatible if Jedi paid attention to whether the client capabilities included a workspace.workspaceEdit dictionary, and provided a suitably formed response either way.

pappasam / jedi-language-server

Inappropriately supplying `documentChanges` during code action resolution #207