Skip to content

Report type check progress to master even when a worker job fails - #2244

Open
soutaro wants to merge 1 commit into
masterfrom
claude/steep-2-0-perf-regression-741jpx
Open

Report type check progress to master even when a worker job fails#2244
soutaro wants to merge 1 commit into
masterfrom
claude/steep-2-0-perf-regression-741jpx

Conversation

@soutaro

@soutaro soutaro commented Jul 2, 2026

Copy link
Copy Markdown
Owner

Problem

steep check hangs forever (all processes idle at 0% CPU) when type checking a file raises an error outside of the signature validation path.

The master waits for a $/steep/typeCheck/progress notification for every file it assigned to workers. When Services::TypeCheckService#typecheck_source (or #validate_signature) raises — for example when building a definition from the RBS environment fails with RBS::DuplicatedMethodDefinitionError — the error is rescued in BaseWorker#run, so the worker survives, but the progress notification for that file is never sent and the type check session never finishes.

This is easy to hit after upgrading to Steep 2.0 / RBS 4, whose core signatures added methods (like private def ruby2_keywords on Module) that conflict with method definitions in a project's own signatures with a different visibility. Minimal reproduction:

# sig/foo.rbs
class Foo
  def bar: () -> Integer
end

class Module
  def ruby2_keywords: (*Symbol) -> void
end
# lib/foo.rb
class Foo
  def bar
    1
  end
end

steep check on this project (with rbs 4.x) hangs forever. Type checking the RBS gem's own v3.10.4 source tree with Steep 2.0 hangs the same way, because its sig/unit_test/spy.rbs defines Module#ruby2_keywords.

Fix

Wrap the four progress-reporting jobs in TypeCheckWorker#handle_job (ValidateAppSignatureJob, ValidateLibrarySignatureJob, TypeCheckCodeJob, TypeCheckInlineCodeJob) with #reporting_typecheck_progress, which reports the file to the master with diagnostics: nil and re-raises the error. The existing error logging and window/showMessage behavior in BaseWorker is unchanged, and the session now finishes: steep check prints Unexpected error reported. 🚨 and exits with status 1 instead of hanging.

Tests

  • Added a regression test that asserts the $/steep/typeCheck/progress notification is sent even when handle_job raises RBS::DuplicatedMethodDefinitionError.
  • test/type_check_worker_test.rb (19 runs) and test/master_test.rb (19 runs) pass.
  • steep check on the reproduction projects above completes with exit status 1 instead of hanging; healthy projects report identical diagnostics as before.

🤖 Generated with Claude Code

https://claude.ai/code/session_019d8VZ7KWvCH1otxL7KEEf5


Generated by Claude Code

The master waits for a `$/steep/typeCheck/progress` notification of every
file it assigned to workers, and the type check session never finishes if
a worker skips reporting a file.

Type checking a file can raise an error outside of the signature
validation path, for example when building a definition from the RBS
environment fails with `RBS::DuplicatedMethodDefinitionError`. This
happens easily after upgrading to RBS 4, whose core signatures added
methods (like `Module#ruby2_keywords`) that conflict with method
definitions in the project's own signatures with a different visibility.

The error was rescued in `BaseWorker#run`, so the worker survived, but
the progress notification for the file was never sent and `steep check`
would hang forever waiting for it.

Wrap the progress-reporting jobs in `#reporting_typecheck_progress`,
which reports the file to the master with `diagnostics: nil` and
re-raises the error, keeping the existing error logging behavior while
letting the type check session finish.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019d8VZ7KWvCH1otxL7KEEf5
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.

2 participants