TSServer: RangeError: Index out of range, exits with code: 134

[JasonKleban]

Typescript 3.3.3333. Haven't tried on @latest or @next yet because of that being a pending migration task - but since there is no matching report of this bug, I have low expectation that it's been fixed.

I searched for issues with:

• "RangeError: Index out of range"
• "TSServer exited with code: 134" but no hits.

My team is getting the following error:

[Info] Using tsserver from: ~\Repos\costar-suite\node_modules\typescript\lib
[Info] Forking TSServer
[Info] Started TSServer
[Error] ReaderError
RangeError: Index out of range
	at Buffer.copy (buffer.js:635:12)
	at l.tryReadContent (~\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\typescript-language-features\dist\extension.js:1:183067)
	at t.Reader.onLengthData (~\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\typescript-language-features\dist\extension.js:1:183633)
	at Socket.t.Reader.constructor.e.on.e (~\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\typescript-language-features\dist\extension.js:1:183400)
	at Socket.emit (events.js:182:13)
	at addChunk (_stream_readable.js:279:12)
	at readableAddChunk (_stream_readable.js:264:11)
	at Socket.Readable.push (_stream_readable.js:219:10)
	at Pipe.onread (net.js:636:20)
[Error] TSServer exited with code: 134

We were able to find this hint microsoft/vscode#71076 which suggested to me that tslint errors in custom tslint rules themselves can cause this issue. Indeed, when I followed the only tslinter advice in a custom tslint rule code to replace a for-loop with a for-in loop, stability greatly improved. It went from crashing repeatedly and continuously to crashing less frequently - after about an hour of use. But the error output is the same.

If there are additional diagnostics that I can run to help pinpoint this issue, I will try it. If this is known as a dupe and/or already fixed, sorry for the noise.

[OneCyrus]

we have the same issue. any workaround without disabling tslint?

[orta]

Do either of you have tslint rules that you can give to help to reproduce the issue?

[OneCyrus]

our tslint.json config looks like this:

{
  "extends": [
    "tslint:recommended",
    "tslint-react",
    "tslint-config-prettier",
    "tslint-plugin-blank-line",
    "tslint-sonarts"
  ],
  "rules": {
    "variable-name": [true, "allow-leading-underscore", "allow-pascal-case"],
    "max-line-length": [true, 200],
    "ordered-imports": [false],
    "object-literal-sort-keys": false,
    "trailing-comma": [true, { "multiline": "never", "singleline": "never" }],
    "arrow-parens": false,
    "only-arrow-functions": [false],
    "no-console": [true],
    "blank-line": [true, "ignore-imports"],
    "prefer-const": false,
    "semicolon": [true, "always", "ignore-bound-class-methods"],
    "object-literal-shorthand": false,
    "array-type": false,
    "class-name": true,
    "whitespace": [
      true,
      "check-branch",
      "check-decl",
      "check-operator",
      "check-module",
      "check-separator",
      "check-rest-spread",
      "check-type",
      "check-typecast",
      "check-type-operator",
      "check-preblock"
    ],
    "jsx-no-bind": true,
    "jsx-no-lambda": true,
    "jsx-boolean-value": false
  },
  "linterOptions": {
    "exclude": ["src/shared/api/api.tsx", "src/shared/api/api_cmdb.tsx"]
  }
}

[orta]

Cool, I've got a focused repro set up which exhibits this bug.

[orta]

What I think is happening: because of typescript-tslint-plugin your linting rules are running inside the TypeScript server. This is fine, except the server uses stdout/in to communicate with the outside world (in this case vscode) so when a console.log comes from the rules (or TSLint even) then that is interpreted as a message by the vscode Reader which it fails to be.

Potential options:

• hook into console.log et al on any TSServer plugins and either raise early inside the server?
• hook into console.log et al on any TSSever plugin and wrap them as log messages to the host somehow?

@mjbvz do you have any ideas?

[mjbvz]

I'd prefer the second option since it would not have any negative user impact. Not sure what the best approach is for wrapping stdout in these plugins though. I think they are imported using a normal require

[orta]

I think changing console in the runtime would do it, that assumes TSServer talks directly via stdout rather than through the console functions (which is my bet) I'll have a look