Standard v1.39.0 breaks Extension

[skovy]

After upgrading from 1.37.0 to 1.39.0 and killing/restarting VSCode, using this extension has started throwing the following error any time trying to format a file.

2024-06-27 15:19:09.049 [error] Error: Header must provide a Content-Length property.
    at Ms.onData (/Users/user/.vscode/extensions/testdouble.vscode-standard-ruby-0.0.16/out/extension.js:2:19059)
    at Socket.<anonymous> (/Users/user/.vscode/extensions/testdouble.vscode-standard-ruby-0.0.16/out/extension.js:2:18789)
    at Socket.emit (node:events:514:28)
    at Socket.emit (node:domain:488:12)
    at addChunk (node:internal/streams/readable:376:12)
    at readableAddChunk (node:internal/streams/readable:349:9)
    at Socket.Readable.push (node:internal/streams/readable:286:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)

[searls]

Does this happen for every project / situation? I can't reproduce it. (In addition to vscode/ruby/standard versions, it could be caused by a VS Code setting or only if you're launching via code . or by opening the folder through a GUI)

[skovy]

It happened after that standard upgrade and restarting VSCode and downgrading resolved the issue. It happens for a few people on our team.

I typically use code . to open the project.

standard:

1.37.0

testdouble.vscode-standard-ruby:

v0.0.16

Ruby:

ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [arm64-darwin22]

VSCode:

Version: 1.90.2
Commit: 5437499feb04f7a586f677b155b039bc2b3669eb
Date: 2024-06-18T22:54:35.075Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 22.6.0

I'll see if I can come up with something reproducible.

[skovy]

Okay, I'm able to repro with this minimal setup: https://github.com/skovy/vscode-standard-ruby-repro. It has the .ruby-version, and the pinned standard gem version, and using the VSCode version I shared above.

I think the key is the .standard_todo.yml file. Without that, it works as expected and we also have this file in our project and removing from there also worked on 1.39.0.

[searls]

A-ha, .standard_todo.yml is almost certainly it. I didn't write that piece / haven't used it and it doesn't have good integration test coverage.

Would you be willing to try to debug / bisect?

[skovy]

I can spend a bit of time on it, what is the most useful information or what debugging did you have in mind?

[searls]

@skovy specifically, (1) what commit introduced the error (if able to run standard from source using gem "standard", path: "some/checkout" and then running git bisect to find the first bad commit) and (2) where in our LSP code is this falling over; the LSP::Logger#puts method may help with puts to vscode's output panel

[skovy]

(1) what commit introduced the error

https://github.com/standardrb/standard/commit/e4fe4d1e7dcef28cdb80f732092dc84dded31bb5

83b5d19407dae2f875116148b6d26f7287ec71ce works as expected, e4fe4d1e7dcef28cdb80f732092dc84dded31bb5 does not.

I spent some time trying to debug but wasn't able to make much progress.

[searls]

Huh, I wonder if maybe these options clearing out todo_* fields for the standard config mattered?

[bobmaerten]

I wonder if it's the same portion of code that handle todo_* files and custom rules import from rubocop like in https://github.com/standardrb/standard/issues/637 ?

[patbenatar]

I ran into a similar problem but for me it was .standard.yml and removing format: progress fixed it 🤷‍♂️

[searls]

@patbenatar that actually makes sense. Opened https://github.com/standardrb/standard/issues/638