Skip to content

fix: end "Compiling" progress when the compile request completes or the connection is lost - #8745

Draft
jozanek wants to merge 2 commits into
scalameta:mainfrom
jozanek:fix/3464-stale-compiling-progress
Draft

fix: end "Compiling" progress when the compile request completes or the connection is lost#8745
jozanek wants to merge 2 commits into
scalameta:mainfrom
jozanek:fix/3464-stale-compiling-progress

Conversation

@jozanek

@jozanek jozanek commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Fixes #3464.

Problem

The "Compiling X" progress is created on BSP build/taskStart and ended only by a matching build/taskFinish. When a build server drops that notification — or dies, hangs, or is replaced mid-compile — nothing else ends it, so the indicator spins for 20–30+ minutes. The only bulk cleanup was reachable exclusively through a successful reconnect + re-import + re-index.

Fix

Every "Compiling" progress now gets a terminal boundary that does not depend on the server behaving:

  • Compile request completionCompilations ends leftover progress when a buildTarget/compile reaches any terminal state, correlated by originId with a target fallback.
  • Connection loss, shutdown, disconnectBuildServerConnection owns an explicit Connected → Reconnecting → Closed lifecycle, and each launcher has a dispatch gate that drops state-mutating notifications once its generation is superseded.
  • buildTarget/run, which only answers when the process exits — its compilations are bounded by an origin-correlated idle policy, and a local run now precompiles first.

Report processing stays independent of the token, so a late build/taskFinish still publishes diagnostics and module status. Also fixed: "Not now" on the reconnect prompt hung the connection permanently, and buildTarget/run on run-only targets.

Known limitations

Documented in code where each applies: compilations started by another BSP client are cleaned only on connection close; an origin-less request can end an overlapping same-target compilation early; task ids are compared across servers; a server emitting no task notifications loses its indicator after the idle threshold.

Follow-up

Compilation identity is keyed by target while BSP lifecycle identity is closer to (connection generation, taskId). A per-launcher compilation tracker with generation provenance would remove the remaining inference and cancellation races — better as a separate change.

@coderabbitai

coderabbitai Bot commented Jul 27, 2026

Copy link
Copy Markdown

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 048630e5-75fb-44ff-b65b-6aed4d04822c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Compiling status never stops

1 participant