Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Build the real SDK fixture before verifying native diagnostic repair

Open Beginner friendly
  • Is something wrong?
#468 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, typescript
Domain
testing

Research direction

Locate the closed-file repair regression test and its project fixture setup; the payload does not name the file, so search for the ten-message bound and next-publication assertions. Read the existing real SDK build oracle, then use it before server initialization and confirm it requires the actual CS0246 error. Done means the original assertions remain intact and the test verifies the repaired publication has zero diagnostics without editor or semantic rescue.

Written by the indexing model from the issue text.

Description

The Linux full Rust CI run executes 623 tests: 622 pass and the existing closed-file repair regression fails because it consumes a second startup publication while labeling it the repair result.

The captured ordering is precise: the first CS0246 publication arrives, the test writes the repaired source, then an already-running startup scan publishes the original error roughly 84–90 milliseconds later, before the native watcher observes the edit. The unchanged isolated test reproduces the failure.

This fixture restores its project but never independently compiles its broken source before server initialization. The initial compiler workspace therefore creates SDK-generated inputs while native watching is already active, starting overlapping initialization work.

Strengthen setup with the existing real SDK build oracle before initialization, requiring the actual CS0246 error and preparing the SDK inputs. Preserve every original next-publication and diagnostic-content assertion, the existing ten-message bound, and the absence of editor or semantic rescue after the repair.

The strengthened setup passes against the unchanged host binaries: the initial Linux run, three additional Linux repetitions, and Windows all pass. The trace now shows the real post-edit native input event followed by the next source publication with zero diagnostics. No production diagnostic behavior, timeout, publication-selection condition, or coverage setting changes.

Dominant language
TypeScript
Stars
168
Forks
9
Avg merge
2h 51m
Merged PRs (30d)
65

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Nimblesite/SharpLsp

All issues in Nimblesite/SharpLsp

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.