Closed diagnostics outside the selected solution directory do not refresh
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- devtools
Research direction
Start with the native input watching and workspace snapshot handling described in the issue, then read diagnostic-ownership-e2e.test.ts for the three regression cases covering F# and C#. Trace how compiler source and project graph determine watch ownership. Done when closed-source edits outside the selected solution directory clear and restore diagnostics automatically, obsolete watches are retired, unchanged subscriptions remain, and stale snapshots are rejected.
Written by the indexing model from the issue text.
Description
A project outside the selected solution directory can be adopted correctly while subsequent closed-source edits leave stale diagnostics in Problems.
Confirmed against feature source 2a59dd10 with real F# and C# projects in the Windows VSIX host:
- Select a solution under
Selected/and open a clean source from a restored project under siblingExternal/. - Verify a genuine error from the external project's unopened source appears once, with the original solution's error preserved.
- Repair that closed source on disk and successfully build its real SDK solution.
Expected: the external error clears automatically and returns when reintroduced, without reopening files or a semantic request. Actual: the original FS0001 or CS0029 remains after the successful repair build.
The new three-case diagnostic-ownership-e2e.test.ts captures both language failures. Native input watching currently follows only the selected solution directory. Watch ownership must follow the actual compiler source and project graph, retain unchanged subscriptions, retire obsolete scopes and reject stale workspace snapshots. Diagnostic results remain owned by Salsa.
- Dominant language
- TypeScript
- Stars
- 168
- Forks
- 9
- Avg merge
- 2h 51m
- Merged PRs (30d)
- 59
Getting set up
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Nimblesite/SharpLsp
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Nimblesite/SharpLsp#468 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Nimblesite/SharpLsp#461 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Nimblesite/SharpLsp#447 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Nimblesite/SharpLsp#444 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Nimblesite/SharpLsp#442 ·
Maintainers usually reply within 1 day
All issues in Nimblesite/SharpLsp
Similar issues
-
Native Web
Difficulty 1/5 Under an hour Newbie friendliness 80/100
digitalfabrik/integreat-app#4517 ·
Maintainers usually reply within 2 days
-
TLS guide repeats certs/ in the certificate directoryPossibly taken @maheshrijal claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
prometheus/docs#3156 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
medusajs/dtc-starter#90 ·
Maintainers usually reply within 1 day
-
usability
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
inmanta/web-console#7632 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
zaidmukaddam/scira#261 ·