fix(lsp): log retried transient errors at warn, not error - #401
Merged
Conversation
bug-ops
force-pushed
the
fix/retried-transient-lsp-errors
branch
from
September 6, 2026 11:49
1f467e8 to
8e40fda
Compare
bug-ops
enabled auto-merge (squash)
September 6, 2026 11:49
message_loop_inner logged every LSP error response at error! unconditionally, before the retry logic in LspClient::request decided whether -32802 (ServerCancelled) or an allowlisted -32801 (ContentModified) would be retried. A request that was retried and succeeded still emitted a spurious ERROR line, causing false-positive alerts in log-based monitoring. Move the severity decision into request(), the only place that knows whether a retry will follow: warn! on each retry attempt, error! only on retry exhaustion or a non-retryable error. All caller-visible error! lines now share one consistent "LSP error response: ..." prefix so log-grep monitoring keeps working for exhaustion cases too. Promote the level-aware tracing capture test helper into the shared test_lsp module, replacing three message-only duplicates in transport, lib, and bridge/notifications.
bug-ops
force-pushed
the
fix/retried-transient-lsp-errors
branch
from
September 6, 2026 11:52
8e40fda to
19f5127
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
message_loop_innerlogged every LSP JSON-RPC error response aterror!unconditionally, beforeLspClient::request's retry logic decided whether-32802(ServerCancelled) or an allowlisted-32801(ContentModified) would be retried. A request that was retried and then succeeded still emitted a spurious ERROR line, causing false-positive alerts in log-based monitoring.request(), the only place that knows whether a retry will follow:warn!on each retry attempt,error!only on retry exhaustion or a non-retryable error/method. All caller-visibleerror!lines share one consistent"LSP error response: ..."prefix, so log-grep monitoring keeps working for exhaustion cases too.test_lspmodule, replacing three message-only duplicates intransport.rs,lib.rs, andbridge/notifications.rs.Closes #392
Test plan
cargo +nightly fmt --all -- --checkcargo clippy --all-targets --all-features --workspace -- -D warningscargo nextest run --workspace --all-features --lib --bins(798 passed, 1 skipped)RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features