TypeError: Cannot read property 'kind' of undefined in 'Object.isImportClause' during 'getCodeFixes' #33726
Assignees
Labels
Bug
A bug in TypeScript
Effort: Moderate
Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual".
Fix Available
A PR has been opened for this issue
Help Wanted
You can do this
Impact: Failed LS Operation
Needs More Info
The issue still hasn't been fully clarified
Rescheduled
This issue was previously scheduled to an earlier milestone
Source: Telemetry
The issue relates to the telemetry in editors
Milestone
Comments
typescript-bot
added
Bug
|
This issue reproduced in the following context: |
|
This issue reproduced in the following context: |
|
Here is a consistent repro from microsoft/monaco-editor#1779 (just paste in the TS playground): import {Event, Context} from "lambda";
import {Item, Result} from "models";
import * as R from "ramda"; |
DanielRosenwasser
added
Effort: Moderate
|
This issue reproduced in the following context: |
RyanCavanaugh
added
the
Rescheduled
|
I tried to reproduce this in many ways, but couldn't reproduce it in a useful way, so a reliable local repro is needed.
|
elibarzilay
added
the
Needs More Info
|
Revised stack format and updated hash. |
|
The client has to be sending a bad error span in the request—whatever the root cause is, it’s almost definitely going to be the same root cause as #32856. It repros reliably in the playground because of a monaco-typescript bug. |
|
Same issue with export.
export const foo = 1;
const barActual result: The following error is printed to the browser console: |
|
This issue reproduced in the following context: |
|
This issue reproduced in the following context: |
|
This issue reproduced in the following context: |
|
This issue reproduced in the following context: |
|
This issue reproduced in the following context: |
|
This issue reproduced in the following context: |
elibarzilay
added a commit
to elibarzilay/TypeScript
that referenced
this issue
Feb 25, 2021
A misbehaved client can sometimes cause the server to reach `deleteDeclaration` with the SourceFile, and it will crash due to no `node.parent`. I couldn't find a good way to create a test for it, but I could trigger it manually by having a file with just a `,`, and sending an explicit `getCodeFixes` command to the server with `errorCodes: [6133]`. I can only guess some scenario in which Emacs or other editors could lead to that, but it's easy to just avoid the crash instead. (Doing the default of deleting the whole thing -- not really important since it's a broken client situation anyway--?) Fixes microsoft#33726
elibarzilay
added a commit
to elibarzilay/TypeScript
that referenced
this issue
Feb 26, 2021
A misbehaved client can sometimes cause the server to reach `deleteDeclaration` with the SourceFile, and it will crash due to no `node.parent`. I couldn't find a good way to create a test for it, but I could trigger it manually by having a file with just a `,`, and sending an explicit `getCodeFixes` command to the server with `errorCodes: [6133]`. I can only guess some scenario in which Emacs or other editors could lead to that, but it's easy to just avoid the crash instead. (Doing the default of deleting the whole thing -- not really important since it's a broken client situation anyway--?) Fixes microsoft#33726
|
This issue reproduced in the following context: |
elibarzilay
added a commit
to elibarzilay/TypeScript
that referenced
this issue
Mar 22, 2021
A misbehaved client can sometimes cause the server to reach `deleteDeclaration` with the SourceFile, and it will crash due to no `node.parent`. I couldn't find a good way to create a test for it, but I could trigger it manually by having a file with just a `,`, and sending an explicit `getCodeFixes` command to the server with `errorCodes: [6133]`. Do three things to improve this: 1. `textChanges.ts`: if we get here with the root node, delete it instead of failing. 2. `fixUnusedIdentifier.ts`: check that we don't `delete` a node that is the whole source file, so the error is more focused (should have more similar failure stacks). 3. `session.ts`: when there was any failure in `getCodeFixes`, check if the input had a diag code that does not appear in the requested text range, and throw an error saying that the failure is probably a result of a bad request. Fixes microsoft#33726
elibarzilay
added a commit
to elibarzilay/TypeScript
that referenced
this issue
Mar 22, 2021
A misbehaved client can sometimes cause the server to reach `deleteDeclaration` with the SourceFile, and it will crash due to no `node.parent`. I couldn't find a good way to create a test for it, but I could trigger it manually by having a file with just a `,`, and sending an explicit `getCodeFixes` command to the server with `errorCodes: [6133]`. Do three things to improve this: 1. `textChanges.ts`: if we get here with the root node, delete it instead of failing. 2. `fixUnusedIdentifier.ts`: check that we don't `delete` a node that is the whole source file, so the error is more focused (should have more similar failure stacks). 3. `session.ts`: when there was any failure in `getCodeFixes`, check if the input had a diag code that does not appear in the requested text range, and throw an error saying that the failure is probably a result of a bad request. Closes microsoft#33726 (probably not fixing it, but making it easier to find the cause)
elibarzilay
added a commit
to elibarzilay/TypeScript
that referenced
this issue
Mar 23, 2021
A misbehaved client can sometimes cause the server to reach `deleteDeclaration` with the SourceFile, and it will crash due to no `node.parent`. I couldn't find a good way to create a test for it, but I could trigger it manually by having a file with just a `,`, and sending an explicit `getCodeFixes` command to the server with `errorCodes: [6133]`. Do three things to improve this: 1. `textChanges.ts`: if we get here with the root node, delete it instead of failing. 2. `fixUnusedIdentifier.ts`: check that we don't `delete` a node that is the whole source file, so the error is more focused (should have more similar failure stacks). 3. `session.ts`: when there was any failure in `getCodeFixes`, check if the input had a diag code that does not appear in the requested text range, and throw an error saying that the failure is probably a result of a bad request. Closes microsoft#33726 (probably not fixing it, but making it easier to find the cause)
elibarzilay
added a commit
to elibarzilay/TypeScript
that referenced
this issue
Mar 24, 2021
A misbehaved client can sometimes cause the server to reach `deleteDeclaration` with the SourceFile, and it will crash due to no `node.parent`. I couldn't find a good way to create a test for it, but I could trigger it manually by having a file with just a `,`, and sending an explicit `getCodeFixes` command to the server with `errorCodes: [6133]`. Do three things to improve this: 1. `textChanges.ts`: if we get here with the root node, delete it instead of failing. 2. `fixUnusedIdentifier.ts`: check that we don't `delete` a node that is the whole source file, so the error is more focused (should have more similar failure stacks). 3. `session.ts`: when there was any failure in `getCodeFixes`, check if the input had a diag code that does not appear in the requested text range, and throw an error saying that the failure is probably a result of a bad request. Closes microsoft#33726 (probably not fixing it, but making it easier to find the cause)
elibarzilay
added a commit
that referenced
this issue
Mar 24, 2021
A misbehaved client can sometimes cause the server to reach `deleteDeclaration` with the SourceFile, and it will crash due to no `node.parent`. I couldn't find a good way to create a test for it, but I could trigger it manually by having a file with just a `,`, and sending an explicit `getCodeFixes` command to the server with `errorCodes: [6133]`. Do three things to improve this: 1. `textChanges.ts`: if we get here with the root node, delete it instead of failing. 2. `fixUnusedIdentifier.ts`: check that we don't `delete` a node that is the whole source file, so the error is more focused (should have more similar failure stacks). 3. `session.ts`: when there was any failure in `getCodeFixes`, check if the input had a diag code that does not appear in the requested text range, and throw an error saying that the failure is probably a result of a bad request. Closes #33726 (probably not fixing it, but making it easier to find the cause)
|
This issue reproduced in the following context: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue comes from crash dumps in telemetry. We've tried to de-duplicate issues on a best-effort basis, comparing the sequence of methods called and the command requested while ignoring line numbers.
TypeScript version prefix: 3.6.3
VSCode version: 1.39.0-insider
Command requested: getCodeFixes
Hitting sessions: 113
Five line hash: c7b31f0235de8b834885fd9d3296b6fc
Stack:
The text was updated successfully, but these errors were encountered: