Fix non-sending of error response on unsupported methods

[Seelengrab]

According to the JSON-RPC spec, the server MUST reply to all RPC calls (except notifications) with a response, in particular when an error occurs (see Section 5 of the JSON-RPC specification). JSONRPC.jl so far has not replied with error code -32601 Method not found when a request was made that is not supported. This PR fixes that, by replying with that error code when encountering a request that is not supported.

Since notifications do not have responses (and should thus be ignorable?), the server from this PR only replies to method requests by checking whether an id field exists or not.

On top of this, I've also consolidated the test in that file a bit, to make testing easier. A temporary directory is now created per test-run, to make testing on a developer machine easier by not leaving artifacts of the previous run behind. I've also prevented deadlocks in the tests, which could happen if the server_task got to the notify call before the main call got to the wait in rare instances (that always seemed to happen on my machine as soon as I expanded the tests).

Since this change should be purely under the hood, I don't think any additional end-user documentation for the VS Code extension or a changelog mention should be required.

It would have been nice to refer to the error code as a constant, but that requires #70 and will thus be done at a later date.

For every PR, please check the following:

• End-user documentation check. If this PR requires end-user documentation in the Julia VS Code extension docs, please add that at https://github.com/julia-vscode/docs.
• Changelog mention. If this PR should be mentioned in the CHANGELOG for the Julia VS Code extension, please open a PR against https://github.com/julia-vscode/julia-vscode/blob/master/CHANGELOG.md with those changes.

[codecov]

Codecov Report

Merging #71 (9682a93) into master (5adc04b) will increase coverage by 0.90%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
+ Coverage   91.46%   92.36%   +0.90%     
==========================================
  Files           4        4              
  Lines         246      249       +3     
==========================================
+ Hits          225      230       +5     
+ Misses         21       19       -2     

Flag	Coverage Δ
unittests	92.36% <100.00%> (+0.90%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/typed.jl	100.00% <100.00%> (ø)
src/core.jl	88.00% <0.00%> (+1.33%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[Seelengrab]

Bump :)

[fredrikekre]

Support in LS.jl?

[Seelengrab]

That's in reference to something about the VSCode extension having built-in support for LS.jl crashing, for telemetry reasons (or so I recall from one of the issues on the LS.jl repo). I'm not familiar with how that works & interacts, but the assumption that the JSONRPC call throws an error is built into LS.jl, yes. Keeping the throwing behavior would need to be moved there, or changed to some other way entirely.

[Seelengrab]

FYI, once #70 is merged, I'll rebase this onto it to no longer have the hard coded magic number here:

https://github.com/julia-vscode/JSONRPC.jl/pull/71/files#diff-9c8bdf42df2c37a8c2f4313ef26b85cddec870ac2aa63e601ef6fdf0c1f56941R83

I'll still have to look into downstream support so that the error call can be removed too. Ideally, the JSON-RPC server itself shouldn't ever crash, but rather refuse operation if it can't handle whatever is thrown at it.