Fix ruff server hanging after Neovim closes

[snowsignal]

Summary

A follow-up to #11222. ruff server stalls during shutdown with Neovim because after it receives an exit notification and closes the I/O thread, it attempts to log a success message to stderr. Removing this log statement fixes this issue.

Test Plan

Track the instances of ruff in the OS task manager as you open and close Neovim. A new instance should appear when Neovim starts and it should disappear once Neovim is closed.

[charliermarsh]

Do you think this would work as expected if we were sending messages via the LSP protocol? Or same issue?

[snowsignal]

Do you think this would work as expected if we were sending messages via the LSP protocol? Or same issue?

That wouldn't work because the I/O with the client has shut down at the point where we log this. However, it would at least fail instantly instead of just waiting forever.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

How can we avoid this in the future? It seems error prone to rely on tracing not being used after the main loop ends (it may even be a dependency that writes a trace, maybe even a third party dependency

[charliermarsh]

Any ideas? I don’t understand the root of the problem well-enough.

[MichaReiser]

Not understanding the root cause is what makes me wary of the fix. It's a good fix to unblock users but it seems fragile to me long term.

[snowsignal]

I can do some further investigation into why the tracing log was blocking.

[ShIRannx]

the ruff server is not the subprocess of nvim. is this relevant to it?